Skip to content
This repository was archived by the owner on Nov 17, 2021. It is now read-only.

Releases: vmware-archive/kubecfg

v0.15.1

10 Feb 18:14
f07144e
Compare
Choose a tag to compare

Release v0.15.0 was broken because we forgot to update the vendored dependencies.

  • Actually vendor go-jsonnet 0.15.0 (#284)

v0.15.0

10 Feb 16:47
2969d0e
Compare
Choose a tag to compare
  • allow commas in tla/extvar options (#281)
  • upgrade go-jsonnet to v0.15.0 (#283)
    There is no I in team, but there is also no bug (report) without u.

v0.14.0

28 Nov 17:17
2d32dcd
Compare
Choose a tag to compare
  • improve error messages when object name is not set (#272)
  • upgrade go-jsonnet to v0.14.0 (#277)
    Three conspiracy theorists walk into a bar; now tell me that's just a coincidence...

v0.13.1

15 Oct 12:40
16949d6
Compare
Choose a tag to compare
  • fix panic in --diff-strategy=subset (#269)
  • fix importer treatment of extvars and TLAs loaded from files (#266)

v0.13.0

24 Sep 01:46
38d6080
Compare
Choose a tag to compare
  • Support all extvar/tla flags from Jsonnet (#265)
  • Omit secrets from diffs (#263)

v0.12.5

26 Aug 15:00
0ed352f
Compare
Choose a tag to compare
  • Fix handling of schema-less CRD objects in k8s >=1.15 … (#261 )

v0.12.4

02 Aug 15:09
a27bea2
Compare
Choose a tag to compare
  • Document KUBECFG_JPATH in --help (#257)

v0.12.2

01 Aug 15:46
Compare
Choose a tag to compare
  • Propagate errors that arise updating objects (#253)

v0.12.0

28 May 00:37
6d1a9b9
Compare
Choose a tag to compare

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.
  • ValidatingWebhookConfiguration and MutatingWebhookConfiguration resources are sorted last during create/update.

v0.11.0

04 Apr 17:17
4b7c1dc
Compare
Choose a tag to compare
  • First release under new bitnami/kubecfg home.
  • This release is identical to v0.10.1, except with all code and other references to ksonnet/kubecfg changed to bitnami/kubecfg.