In Kubernetes, the kubectl apply command is idempotent, meaning that successive applies of the same objects results in no change occurring within the cluster.
Additionally, kubectl has a diff subcommand that let's you implement your own idempotence workflow. For example:
This last type of workflow, while seemingly duplicative of just a standard kubectl apply, is important for configuration management tools such as Puppet, Salt, Chef, etc. These tools treat a command execution as an "applied resource", and thus you want to avoid running a given configuration command if it doesn't need to be run. Without support for this concept, the tools will execute the command every time they apply the configuration, which leads to reporting for the given tools showing that "changes have occurred" on the system.
In enterprise environments, where this type of reporting is viewed by compliance or security teams, these "false positives" can be quite annoying.
Another benefit to a "diff" command is so that operators or CI systems can display/review changes before applying them.
Expected Behavior
User can run a calicoctl diff (new subcommand) to detect changes in a Calico object.
Current Behavior
No analogous command to diff exists currently, I don't think.
The calicoctl get command could potentially be used to implement a custom workflow to detect changes in the extant object. In principle this is fine, however it's not clear how "safe" this custom workflow will be to changes in Calico itself (e.g. changes in how Calico displays resources or change in data model, etc.).
Possible Solution
Not familiar with Calico internals, but it seems like calicoctl apply might already incorporate some kind of object diffing. At least, if I calicoctl apply the same object twice in a row, its metadata:resourceVersion number stays the same.
If true, perhaps that diffing can be exposed as a subcommand.
This seems like a reasonable request, thank you for submitting it.
If anyone has interest on working on this please comment here and we'll be happy to discuss this and review any PRs.
In Kubernetes, the
kubectl apply
command is idempotent, meaning that successive applies of the same objects results in no change occurring within the cluster.Additionally,
kubectl
has adiff
subcommand that let's you implement your own idempotence workflow. For example:This last type of workflow, while seemingly duplicative of just a standard
kubectl apply
, is important for configuration management tools such as Puppet, Salt, Chef, etc. These tools treat a command execution as an "applied resource", and thus you want to avoid running a given configuration command if it doesn't need to be run. Without support for this concept, the tools will execute the command every time they apply the configuration, which leads to reporting for the given tools showing that "changes have occurred" on the system.In enterprise environments, where this type of reporting is viewed by compliance or security teams, these "false positives" can be quite annoying.
Another benefit to a "diff" command is so that operators or CI systems can display/review changes before applying them.
Expected Behavior
User can run a
calicoctl diff
(new subcommand) to detect changes in a Calico object.Current Behavior
No analogous command to
diff
exists currently, I don't think.The
calicoctl get
command could potentially be used to implement a custom workflow to detect changes in the extant object. In principle this is fine, however it's not clear how "safe" this custom workflow will be to changes in Calico itself (e.g. changes in how Calico displays resources or change in data model, etc.).Possible Solution
Not familiar with Calico internals, but it seems like
calicoctl apply
might already incorporate some kind of object diffing. At least, if Icalicoctl apply
the same object twice in a row, itsmetadata:resourceVersion
number stays the same.If true, perhaps that diffing can be exposed as a subcommand.