Issue 1:
kubectl get <resource_name> prints all the resource info as a table by default. Sometimes there is just too much data and one row of the table is not able to fit in one line. It takes time to comprehend that entire output. It may be particularly useful to restrict columns by name. So for example in context of resource pod, something like..

kubectl get pods --filter names

that would only pod names instead of an entire table containing all columns like POD, HOST, STATUS, CREATED, etc. would be particularly useful.

Exact interface for this might need to be discussed and planned on a wiki. (I'll try to update this issue with a more detailed suggest if I can think of something)

Issue 2:
I am working with Huawei PaaS team on Ubernetes Phase I implementation, and focus on Uberenetes scheduler. I created a sequence diagram to illustrate the process of ubernetes scheduler and want to start some discussions.

A general principle design spec

Currently clusterSelector (implemented as a LabelSelector) only supports a simple list of acceptable clusters. Workloads will be evenly distributed on these acceptable clusters in phase one.

Need to make agreement that "evenly distributed" simply means cloning Federation-RC as sub-RC, and assign target clusters, replicas will not be cared in Federation level, that is sub-RC will keep the same value for replicas of Federation RC.

Supported cases in phase I

#1. User specifies clusterSelector in RC Spec, e.g. The following RC is created in Federation-1 with 3 running clusters a, b and c.

apiVersion: v1
kind: ReplicationController
metadata:
name: nginx-controller
spec:
replicas: 5
...
clusterSelector:
name in (a, b)

The result will be, if scheduling succeeds, the two sub-RC are created, each RC has 5 replicas, one RC is assigned to cluster a, the other RC is assigned to cluster b.

#2. User does not specify clusterSelector in RC Spec, e.g. The following RC is created in Federation-1 with 3 running clusters a, b and c.

need to discuss should we support this case?

apiVersion: v1
kind: ReplicationController
metadata:
name: nginx-controller
spec:
replicas: 5
...

As a result, the RC will be cloned to 3 sub-RC and assigned to all running clusters a, b, and c in Federation-1.

Code logics, details in the diagram

most of code of package plugin/cmd/kube-scheduler could be reused, minor changes include package import to ube-scheduler, and remove some unnecessary logics.

The design of ube-scheduler will be created based on k8s scheduler code, but with some logical changes, highlighted in RED in the sequence diagram.

There is no need for binding pod, so Ubernetes scheduler will not check scheduled Federation RC, no code like scheduledPodPopulator

Only default predicate and priority plugins are supported in P1

No need to watch Federation Services, as there is no need for spreading sub-RC of same Federation Service

About scheduler plugins

a). There will be two predicates plugins, MatchClusterSelector and RCFitsResources

b).

From above cases description, I did not see requirement to do prioritize, so only a dummy priority plugin will be created.

The plugin will return a list of clusters, the Federation RC will be cloned as sub-RC and each element of the cluster list will be assigned as target.

As #1 described, no need for cluster binding, scheduling done after step 5.

Dependencies

Need definition of cluster, federation RC and sub RC

Cluster entity is already in WIP

Federation RC and sub RC definition need to be settled ASAP.

Need api of accessing new defined entities in pkg/client/cache/listers.go