search

projectcalico / calico

Cloud native networking and network security
https://docs.tigera.io/calico/latest/about/
Apache License 2.0
5.98k stars 1.33k forks source link

Idempotent application of Calico objects #3001

Open jcmcken opened 4 years ago

jcmcken commented 4 years ago

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:

$ kubectl diff -f config.yml | grep status || kubectl apply -f config.yml

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.

tmjd commented 4 years ago

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.