Issue 1:
Following PR #12001.

From what I can gather, there are 3 sets of changes that need to be made to finish off the experimental api support. Deep copies and conversions need to be autogenerated, the client library needs support, as does kubectl.

Within the master, we now have types (and their conversions and deep copies) being generated in multiple packages. However, types from the experimental api may refer to types in the standard api. However, since the deep copies and conversions are not exported, they must be regenerated in each package. This leads to duplicate (albeit autogenerated) code. We can avoid this by modifying the autogeneration code to use Scheme.DeepCopy/Scheme.Convert when we find a type that has been declared in another package. Alternatively, we may move the conversion and deepcopy functions to a common location. The disadvantage with the second approach is that we have a new package that needs to be imported everywhere as both pkg/api and pkg/expapi should be initialized before adding the functions (it may be safe to add the functions before the types, but if so this isn't clearly stated anywhere).

For the client library, the Config object causes trouble.

type Config struct {
// Host must be a host string, a host:port pair, or a URL to the base of the API.
Host string
// Prefix is the sub path of the server. If not specified, the client will set
// a default value. Use "/" to indicate the server root should be used
Prefix string
// Version is the API version to talk to. Must be provided when initializing
// a RESTClient directly. When initializing a Client, will be set with the default
// code version.
Version string
// Codec specifies the encoding and decoding behavior for runtime.Objects passed
// to a RESTClient or Client. Required when initializing a RESTClient, optional
// when initializing a Client.
Codec runtime.Codec

// Server requires Basic authentication
Username string
Password string

// Server requires Bearer authentication. This client will not attempt to use
// refresh tokens for an OAuth2 flow.
// TODO: demonstrate an OAuth2 compatible client.
BearerToken string

// TLSClientConfig contains settings to enable transport layer security
TLSClientConfig

// Server should be accessed without verifying the TLS
// certificate. For testing only.
Insecure bool

// UserAgent is an optional field that specifies the caller of this request.
UserAgent string

// Transport may be used for custom HTTP behavior. This attribute may not
// be specified with the TLS client certificate options. Use WrapTransport
// for most client level operations.
Transport http.RoundTripper
// WrapTransport will be invoked for custom HTTP behavior after the underlying
// transport is initialized (either the transport created from TLSClientConfig,
// Transport, or http.DefaultTransport). The config may layer other RoundTrippers
// on top of the returned RoundTripper.
WrapTransport func(rt http.RoundTripper) http.RoundTripper

// QPS indicates the maximum QPS to the master from this client. If zero, QPS is unlimited.
QPS float32

// Maximum burst for throttle
Burst int
}

In particular, the Prefix, Version, and Codec fields need to be changed for both experimental support and eventual multiple api group support. These fields also exist within client.RESTClient, although Codec is the only field there which is public. It's likely that these fields are not used by many clients since we default them in helper.go, so breaking this may be acceptable. For actually adding experimental objects, we could create a new Experimental field in Client of type ExperimentalClient (also embedding a *RESTClient) that would be not have to be explicitly initialized (i.e. it would be created in the Client's constructor). So from a user's perspective, they would run something like

c, err := client.New(config)
// err handling
list, err := client.Experimental.DaemonController(ns).List(selector)

Finally, for the changes to kubectl, proxy needs to proxy the experimental prefix if it is enabled, api-versions needs to print out information for the experimental api, validation (via swagger) needs to check the experimental api, and since kubectl uses the client library, kubectl support cannot be completed until support is added to client library.

@smarterclayton @bgrant0607 @nikhiljindal @lavalamp

Issue 2:
Hello,

I would like to make rolling update by node:

Select one node

Stop all pods of the RC on this node.

Start new pods on this node

Select an other node

Stop all pods of the RC on this node.

...

Questions:

Is this using is OK with Kubernetes philosophy ?

Is there any way to do it right now ?

If not, which files are concerned by this ?

I can patch it to get something like: kubectl rolling-update frontend-v1 -f frontend-v2.json --by-node

Thanks