In order to improve the UX of kubeadm, it was decided to introduce the
following subcommands:
- `kubeadm config print` - this is currently only a placeholder for subcommands
that deal printing of some kind of configuration.
- `kubeadm config print init-defaults` - prints the default combination of
InitConfiguration and ClusterConfiguration. Selected component configs can be
printed too if the `--component-configs` command line switch is used.
- `kubeadm config print join-defaults` - prints the default JoinConfiguration.
This command also supports the use of `--component-configs`.
- `kubeadm config print-defaults` is deprecated in favor of
`kubeadm config print init/join-defaults`.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
In some storage tests, kubelet is stopped first and the test check node
NotReady state. However, if it fails to have this state, kubelet could
not be restarted because the defer function is placed after the stop
kubelet command. This PR fixes this issue.
If the custom resource participates the spec/status convention, the
metadata.generation of the CR increments whenever there is any change,
except for the changes to the metadata or the changes to the status.
If the CR does not participate the spec/status convention, the
metadata.generation of the CR increments whenever there is any change,
except for the changes to the metadata.
A CR is considered to participate the spec/status convention if and only if the
"CustomResourceSubresources" feature gate is turned on and when the CRD
has `.spec.subresources.status={}`.
The previous version forced us to create AWS IAM Policies that are too
permissive when dealing with volumes. That's because:
1. Volumes were created without tags that identifies the new resource as
managed by the cluster. So technically the resourse, at creation time,
is not owned by the cluster.
2. Tags were added to the volume making the resource now managed by the
cluster. The problem being that it could make ANY volume as managed by the
cluster. Thus allowing resources that aren't really part of the cluster,
or part of no cluster at all, to become a resource managed by the cluster.
By combining the operations we can both make the code simpler, since we
don't need to deal with deleting a volume in case we can't apply tags to
it, plus the security model gets a nice improvement.
When doing upgrades kubeadm generates new manifest and
waits until kubelet restarts correspondent pod.
However, kubelet won't restart pod if there are no changes
in the manifest. That makes kubeadm stuck waiting for
restarted pod.
Skipping upgrade if new component manifest is the same as
current manifest should solve this.
Fixes: kubernetes/kubeadm#1054
update bazel and fix goftm
use defaultStorageAccountKind
fix test failure
update godep license file
fix staging godeps issue
update staging godeps
fix comments, use one API call for file creation
