cli: output coordinator policy on generate

[burgerdev]

As soon as we embed a default coordinator policy into the CLI, the set
and verify subcommands will stop working if the coordinator policy does
not match expectations. Thus, we need to make users aware if we detect a
non-default coordinator among the deployments.

If the CLI encounters an unexpected coordinator policy in the input
YAML, it prints the policy hash to stdout and warns on stderr. This
provides the user with two choices, depending on their workflow:

1. Users that don't expect changes to the coordinator policy can abort
   right away to check why the policy changed. But even if they ignore
   the output entirely, set will still fail closed.
2. Users that deliberately changed the coordinator but want to verify it
   nonetheless. These users need to pass the output to the set command,
   if it was not empty.

Implementation note: I decided to add a field to the deployment type so that we don't need to do the check in policiesFromKubeResources, which is called by both generate and set.

[katexochen]

The checking is only enabled when the default policy is not empty, i.e. when the coordinator policy is actually checked.

I think we should enable this by default, even if we did not previously inject a default policy hash into the CLI. This way, people can already check the policy hash by setting it via flag, and we can move our workflow to use the policy hash from the get output instead of using the yq script.

[katexochen]

We should not just print to os.Stderr, but rather hand in an io.Writer so we can use cmd.ErrOrStderr.

Might be even better to just return (hash string, ok bool) so we can keep the user interaction in the command. Also, we might want to write the hash to stdout instead, so it can be easily processed.

[burgerdev]

Thanks for the suggestion, sounds much better.

[burgerdev]

The checking is only enabled when the default policy is not empty, i.e. when the coordinator policy is actually checked.

I think we should enable this by default, even if we did not previously inject a default policy hash into the CLI. This way, people can already check the policy hash by setting it via flag, and we can move our workflow to use the policy hash from the get output instead of using the yq script.

Instead of outputting from generate for two use cases (inform the user about non-standard deployment; make hash available for set), how about adding the coordinator policy hash as a field to the manifest? That would allow trivial separation of human-readable messages and machine-parseable information, and the workflow until set would "just work" even with a non-standard policy.

[malt3]

Instead of outputting from generate for two use cases [..], how about adding the coordinator policy hash as a field to the manifest? [...]

I think that would blur the lines of what the manifest currently is meant to be (the thing that the coordinator uses to verify pods).
Maybe that would be acceptable if the local file is not just the manifest, but instead something like settings.json, containing the manifest and other settings (like the policy hash).

[katexochen]

Maybe that would be acceptable if the local file is not just the manifest, but instead something like settings.json, containing the manifest and other settings (like the policy hash).

I'm not sure we should go into this direction. Anyway out of scope of this PR, as this needs proper design discussion.

[burgerdev]

Agreed to the purpose of the manifest. For this PR here, should we stick to passing the hash via stdout then? Maybe we could at least offer a machine-readable output variant (say nunki generate --json).

[katexochen]

Maybe we could at least offer a machine-readable output variant (say nunki generate --json).

I don't see an immediate need for that as long as we are only outputting a single value.

[burgerdev]

I updated the PR description with the changed rationale.