Issue 1:
Problem: the following codes just hang and never returns

clientset, err := kubernetes.NewForConfig(config)
pods, err := clientset.Core().Pods("").List(api.ListOptions{Watch:true})

while codes like:

watch, err := clientset.Core().Pods("").Watch(api.ListOptions{})

work as expected.

IMHO, the first use is kind of misleading.

Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see http://kubernetes.io/docs/troubleshooting/.):

What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.):

Is this a BUG REPORT or FEATURE REQUEST? (choose one):

Kubernetes version (use kubectl version):

Environment:

Cloud provider or hardware configuration:

OS (e.g. from /etc/os-release):

Kernel (e.g. uname -a):

Install tools:

Others:

What happened:

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else do we need to know:

Issue 2:
Talking with @ericchiang a bit, my understanding of the RBAC PolicyRule's apiGroups field is that it determines which API groups the authorizer looks for resources in. For example, if you want to authorize the resource "deployments," you need to explicitly include the "extensions" API group:

kind: "Role"
apiVersion: "rbac.authorization.k8s.io/v1alpha1"
metadata:
name: "deployer"
rules:
- apiGroups: ["extensions"]
resources: ["deployments"]
verbs: ["*"]

The reason for this is to help disambiguate resources if resources of the same name exist in more than one API group. However, because both the apiGroups and resources fields are arrays, it actually creates a matrix of request allowances which is likely not what the user intended. For example, say I want to authorize requests for "resource1" in the API group "group1" and "resource2" in the API group "group2." I'd write this:

kind: "Role"
apiVersion: "rbac.authorization.k8s.io/v1alpha1"
metadata:
name: "problem"
rules:
- apiGroups: ["group1", "group2"]
resources: ["resource1", "resource2"]
verbs: ["*"]

If it turns out that resources with those two names both happen to exist in both API groups, then I've actually authorized four different resources instead of the intended two. In order to properly express what I want, I'd have to create two rules, each with one group and one resource.

Because of this behavior, it doesn't make sense to me that the apiGroups field should allow more than one value. Either it should be limited to a single API group name, to prevent any accidental overlap of resource names between API groups, or it should be removed entirely, and resources should be qualified with their API group as a prefix. Below are examples of them written in those two different ways:

kind: "Role"
apiVersion: "rbac.authorization.k8s.io/v1alpha1"
metadata:
name: "problem"
rules:
- apiGroups: "group1"
resources: ["resource1"]
verbs: ["*"]
- apiGroups: "group2"
resources: ["resource2"]
verbs: ["*"]

kind: "Role"
apiVersion: "rbac.authorization.k8s.io/v1alpha1"
metadata:
name: "problem"
rules:
- resources: ["group1/resource1", "group2/resource2"]
verbs: ["*"]

The first example is basically what you have to do today to get exactly the desired semantics, with the added benefit of apiGroups's type enforcing that you do it this way. The second example is less verbose because you can do what you want in a single rule. The downside to the second example is that lists of resources become more verbose in general.

Refs kubernetes/enhancements#2.