Sensu-go: Allow pruning config on create

[agoddard]

It would be great (albeit scary) to be able to apply a --prune or similar flag to sensuctl create. This would remove existing config and replace it with the config coming from the create command, thus making Sensu's config match the state declered in the file(s) passed to create

Expected Behavior

sensuctl create -f config.yml --prune should destroy any config on the server, replacing it with the config from config.yml

Current Behavior

with no --prune command, the config from config.yml would be merged with the config on the server

Possible Solution

Context

As the last step of a CI/CD pipeline, having a sensuctl create command run that will match the state of the server with that of the config will allow for operators to know that when the deployment succeeds, the state of the server matches the state of the config that was just deployed in the pipeline

[echlebek]

Likely relevant to @roganartu 's interests :smile:

edit: typo

[roganartu]

Related issues that @echlebek is referencing: #2631 #2613

This matches the CI/CD-friendly behaviour I was envisioning when I originally raised those issues.

We currently do this with xargs to sensuctl create followed by a call to a Python script for each resource type the pipeline manages that queries sensu for existing resources of that type and deletes any that aren't present in the resource files.

[calebhailey]

Unabridged notes from a recent discussion w/ @agoddard:

• Depends on support for --namespace overrides from sensuctl.
• This would be a very complementary feature with support for processing directories of resource manifests (e.g. sensuctl create -f /path/to/dir/)
• Add support for per-resource pruning, as well as multi-resource-type pruning; e.g. --prune-pipeline (prune all checks, filters, mutators, handlers, assets, etc; but not users/roles/namespaces, etc), --prune-checks, etc.

Examples:

$ sensuctl create -f manifests.json --namespace foo --prune-all
$ sensuctl create -f manifests.json --namespace foo --prune-pipeline 
$ sensuctl create -rf /path/to/config/dir/ --namespace foo --prune-pipeline
$ sensuctl create -f manifests.json --namespace foo --prune-checks
$ sensuctl create -f manifests.json --namespace foo --prune-handlers

_EDIT: not adding a lot of explanation here as I suspect the ideas conveyed by these examples are somewhat obvious; just providing them as (hopefully) inspiration for eventual implementation._

[calebhailey]

Related? https://github.com/sensu/sensu-go/issues/2980#issuecomment-496237293

[calebhailey]

Per @palourde's comment in #2980 👆 I wonder if part of the solution here is to tighten up our implementation of sensuctl create -f so that it is actually an _imperative object configuration_, because I don't believe it is at this time (e.g. you can run sensuctl create -f foo.yaml more than once on the same resources). Alternatively, we might consider changing the command to sensuctl apply -f if we believe it is a declarative object configuration?

_NOTE: we do correctly support _imperative commands_ such as sensuctl create <resource>. See the excellent Kubernetes Object Management documentation for reference._

[echlebek]

Good morning!

As Simon mentions in #2980, sensuctl is already imperative, and being able to run it more than once with the same resource does not change that. Each invocation completely replaces the named resource, with standard HTTP PUT semantics.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/PUT

With PUT, the result of a request is always the same, as long as the request URL and body are the same. This has some nice properties. Consider the following scenario:

A client wants to create or update a resource, but doesn't know the current state of the system. With PUT, they can simply "fire and forget", and be confident the resource will be atomically created or updated. We say that PUT is idempotent, because it has no side effects.

If the system were to take a different action depending on the existence of the resource, then the client would have to first retrieve the resource before making another request. In the meantime, the state of resource could change, if another client made changes to it. This can lead to a surprising failure.

I do not wish to substantially change the semantics of sensuctl create, as it is a thin wrapper over this HTTP PUT API. If a different behaviour is needed, it would be simpler and more cost effective to build a new tool, instead of trying to overload the existing one. I'll leave the naming up to others this time! :smile:

[portertech]

sensuctl configuration pruning

[nikkictl]

sensuctl prune has been implemented in https://github.com/sensu/sensu-enterprise-go/pull/919.. closing this out!