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

Nope!

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

kubectl, apply, scheduledjob, batch/v1

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

BUG REPORT

Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.1", GitCommit:"33cf7b9acbb2cb7c9c72a10d6636321fb180b159", GitTreeState:"clean", BuildDate:"2016-10-10T18:19:49Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.1", GitCommit:"33cf7b9acbb2cb7c9c72a10d6636321fb180b159", GitTreeState:"clean", BuildDate:"2016-10-10T18:13:36Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"}

Environment:

Cloud provider or hardware configuration: AWS

OS (e.g. from /etc/os-release): Debian GNU/Linux 8 (jessie)

Kernel (e.g. uname -a): Linux ip-172-20-61-42 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) x86_64 GNU/Linux

Install tools: kops

Others: n/a

What happened:

kubectl apply emits an error when applying changes to an existing ScheduledJob.

What you expected to happen:

kubectl apply should have successfully applied changes to the existing ScheduledJob.

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

Given this ScheduledJob manifest:

# scheduledjob.yaml
# From http://kubernetes.io/docs/user-guide/scheduled-jobs/#creating-a-scheduled-job
apiVersion: batch/v2alpha1
kind: ScheduledJob
metadata:
name: hello
spec:
schedule: 0/1 * * * ?
jobTemplate:
spec:
template:
spec:
containers:
- name: hello
image: busybox
args:
- /bin/sh
- -c
- date; echo Hello from the Kubernetes cluster
restartPolicy: OnFailure

The first apply succeeds:

$ kubectl apply -f scheduledjob.yaml
scheduledjob "hello" created

The second one fails:

$ kubectl apply -f scheduledjob.yaml
error: error when applying patch:

to:
&{0xc8200bd740 0xc8202f8ee0 sandbox hello scheduledjob.yaml &ScheduledJob{ObjectMeta:k8s_io_kubernetes_pkg_api_v1.ObjectMeta{Name:hello,GenerateName:,Namespace:,SelfLink:,UID:,ResourceVersion:,Generation:0,CreationTimestamp:0001-01-01 00:00:00 +0000 UTC,DeletionTimestamp:<nil>,DeletionGracePeriodSeconds:nil,Labels:map[string]string{},Annotations:map[string]string{kubectl.kubernetes.io/last-applied-configuration: ,},OwnerReferences:[],Finalizers:[],ClusterName:,},Spec:ScheduledJobSpec{Schedule:0/1 * * * ?,StartingDeadlineSeconds:nil,ConcurrencyPolicy:,Suspend:nil,JobTemplate:JobTemplateSpec{ObjectMeta:k8s_io_kubernetes_pkg_api_v1.ObjectMeta{Name:,GenerateName:,Namespace:,SelfLink:,UID:,ResourceVersion:,Generation:0,CreationTimestamp:0001-01-01 00:00:00 +0000 UTC,DeletionTimestamp:<nil>,DeletionGracePeriodSeconds:nil,Labels:map[string]string{},Annotations:map[string]string{},OwnerReferences:[],Finalizers:[],ClusterName:,},Spec:JobSpec{Parallelism:nil,Completions:nil,ActiveDeadlineSeconds:nil,Selector:nil,ManualSelector:nil,Template:k8s_io_kubernetes_pkg_api_v1.PodTemplateSpec{ObjectMeta:ObjectMeta{Name:,GenerateName:,Namespace:,SelfLink:,UID:,ResourceVersion:,Generation:0,CreationTimestamp:0001-01-01 00:00:00 +0000 UTC,DeletionTimestamp:<nil>,DeletionGracePeriodSeconds:nil,Labels:map[string]string{},Annotations:map[string]string{},OwnerReferences:[],Finalizers:[],ClusterName:,},Spec:PodSpec{Volumes:[],Containers:[{hello busybox [] [/bin/sh -c date; echo Hello from the Kubernetes cluster] [] [] {map[] map[]} [] nil nil nil nil false false false}],RestartPolicy:OnFailure,TerminationGracePeriodSeconds:nil,ActiveDeadlineSeconds:nil,DNSPolicy:,NodeSelector:map[string]string{},ServiceAccountName:,DeprecatedServiceAccount:,NodeName:,HostNetwork:false,HostPID:false,HostIPC:false,SecurityContext:nil,ImagePullSecrets:[],Hostname:,Subdomain:,},},},},},Status:ScheduledJobStatus{Active:[],LastScheduleTime:<nil>,},} &TypeMeta{Kind:,APIVersion:,} 12601558 false}
for: "scheduledjob.yaml": error when serializing current configuration from:
&TypeMeta{Kind:,APIVersion:,}
for: "scheduledjob.yaml": no kind "ScheduledJob" is registered for version "batch/v1"

Anything else do we need to know:

ScheduledJob is enabled on the apiserver via --runtime-config=batch/v2alpha1=true

first reported downstream at helm/helm#1408

Issue 2:
Background

We are migrating components other than kube-apiserver in the main repository to use client-go. The end goal is removing most parts of the pkg/client out of the main repository, and developing clients in client-go. We believe it will increase the development velocity in the long run.

As the first step, we will migrate components to use the client-go located in the staging area of main repository.

Goal

The migration involves huge changes. We want to find a manageable way.

We want to break the migration into multiple PRs of sizes reasonable for review.

We want to reduce the operational cost the k8s community needs to bear with during the migration.

[Abandoned] Approach 1: migrating one component at a time

For example, first convert kube-controller-manager (#29934) to use client-go, then converting kubelet, etc.

The problem is: Components migrated to client-go will use versioned types defined in client-go, e.g., client-go#v1.Pod (client-go is the repo name, v1 is the package name), while the remaining components keep using unversioned types defined in the main repository, e.g., kubernetes#api.Pod. The difference in the types causes a dilemma for the packages shared by both groups of components, e.g., pkg/volume. We’ve considered two workarounds:

[Abandoned] Approach 1.1: Make two copies of the shared dependencies

We are going to take this approach if the community can bear with the disadvantages.

We make two copies of the shared dependencies, one keeps using kubernetes#api.Pod, the other one uses client-go#v1.Pod. We will provide a script to do the copy. I had experimented to migrate only kube-controller-manager, it turned out we at least need to maintain copies of these package:

pkg/util/node (1 file)

pkg/util/system (one liner)

pkg/volume (147 files) @saad-ali

pkg/serviceaccount (5 files)

pkg/fieldpath (3 files)

pkg/controller/deployment/util (2 files) @janetkuo

Disadvantages:

We need to add a verify script to force developers who make changes to the original package to run the update script to keep the copy in sync.

[Abandoned] Approach 1.2: Converting before calling shared packages

We convert client-go#v1.Pod to kubernetes#api.Pod before passing the object to shared packages. The conversion requires two steps: i). using the unsafe package to forcefully convert client-go#v1.Pod to kubernetes#v1.Pod, ii). Use api.Scheme to convert to kubernetes#api.Pod.

Disadvantages:

Converting to api.Pod will apply the defaults. Perhaps this will cause problem if a controller is creating API objects.

Conversion is inefficient.

[Abandoned] Approach 2: migrating in a developing branch

We’ll take this approach if the community finds the operational cost of the first approach is too high. We will make a developing branch, accumulating PRs and getting reviews, and finally merge with the master branch the migration is done for all binaries.

Disadvantages:

The developing branch is in an uncompilable state until the most components are migrated.

Perhaps the final merge will be challenging. I will try to reduce the workload by

capture most rewrites in a script

finish the migration during the 1.5 code freeze

[Picked] Approach 3: migrating to the versioned clients during the code freeze

Details are in this comment

Please let us know if you can bear with the cost of approach 1.1.

@kubernetes/sig-api-machinery @smarterclayton @deads2k @liggitt