feat: general mechanism to allow a container (or init-container) environment to overridden from the OperatorOverride

[k-wall]

A general mechanism to allow a container (or init-container) environment to overridden from the OperatorOverride. Currently it is just applied to the canary image.

(The scope of this PR has been broadened. Originally we wanted a mechanism to allow canary reconcile and connection check interval to be overridden to help investigate MGDSTRM-8698 by having the ability to turn off the connection check.

The scope has been extended to include admin server. I note that strimzi does let let you override envvars for any of its deployments.

[MikeEdgar]

I think this change would be a prime candidate to use additionalProperties in OperandOverride. For example, the canary could look for a Map<String, EnvVar> List<EnvVar> entry under additionalProperties.get("env") that could contain any user-provided environment entries and pass them through to the canary container. That leaves a door open to configure individual canary instances rather than having the config apply to the entire fleet.

[k-wall]

I think this change would be a prime candidate to use additionalProperties in OperandOverride. For example, the canary could look for a Map<String, EnvVar> List<EnvVar> entry under additionalProperties.get("env") that could contain any user-provided environment entries and pass them through to the canary container. That leaves a door open to configure individual canary instances rather than having the config apply to the entire fleet.

I like that idea. I think in the cm it would look like:

canary:
  image: quay..
  env:
   - name: FOO
     value: bar

but I don't immediately see how we'd persuade Jackson to manufacture EnvVar objects rather (than Map). What am I missing?

We could just spin off a separate List<EnvVar> env property on the OperandOverride I suppose rather than use the catch-all.

[shawkins]

but I don't immediately see how we'd persuade Jackson to manufacture EnvVar objects rather (than Map). What am I missing?

Use something like Serialization.jsonMapper().convertValue(map, EnvVar[].class) with the map from the env field.

[MikeEdgar]

We could just spin off a separate List<EnvVar> env property on the OperandOverride I suppose rather than use the catch-all.

+1

[k-wall]

@shawkins @MikeEdgar how does this look?

I needed to make a decision about whether the override feature should apply to any environment variable, even those that probably shouldn't be overridden. I thought about separating a container's env var into a set of those which are reasonable to override and those which are not (KAFKA_BOOTSTRAP_SERVERS for instance). In the end I decided it were simpler to assume that the feature would be used wisely.

I think we should apply the same pattern to the other containers, but what to give you chance to comment first.

[MikeEdgar]

This looks good. Just one comment which supports what you said about making this more generally usable for any of the operands.

[SamBarker]

LGTM