v0.12.0
Major change: Updates to existing objects are now performed using client-side strategic-merge-patch.
TL;DR: Previously, kubecfg treated "unspecified" fields as "don't care". Now it interprets "unspecified" fields that were previously specified as "set to default". So now you can remove an annotation/label from your jsonnet, and kubecfg update will remove it from the server.
Previously, kubecfg used a simple json-merge. In json-merge (old behaviour) removing a field from a "map" (eg: metadata.annotations or labels) did not remove it from the server - you needed to explicitly set the field back to the default value (ie: "unspecified" meant "don't care"). This was occasionally surprising and different to the way other tools in this space work (kubectl apply, ksonnet, qbec). Now, kubecfg uses strategic-merge-patch and does a 3-way diff to notice that the field has been removed from the previous kubecfg run (so now "added and later removed" means "clear the value (set to the default)").
New objects, or objects without the "last-applied-configuration" annotation, fall back to the same behaviour as previous versions of kubecfg. The "last-applied-configuration" annotation will be added on the first kubecfg update using >=v0.12.0. It is safe to mix kubecfg versions, although the behaviour of "unspecified" (or removed) values will be subtly different, as above.
Notable differences vs kubectl apply: kubecfg does the strategic-merge-patch on the client-side (for consistency across server versions), driven by schema information. The "last-applied-configuration" annotation is also stored in a compressed form, so has a reduced impact on the maximum resource size. See PR #246 for details.
Other changes:
- Reduced output noise:
Only one of "Creating ..." or "Updating ..." will be printed. No message at all if the object has no change. kubecfg -vv(or greater) now also enables client-go REST logging.ValidatingWebhookConfigurationandMutatingWebhookConfigurationresources are sorted last during create/update.