How to control agent command line?

[MikeSpreitzer]

We now want some control over the OCM Status Add-On Agent command line, to allow control over log verbosity and client-side self-restraint in the request rate to the apiservers. How should this be done?

In terms of the OCM Status Add-On Controller, there are two approaches we could take.

The simplest would be to define some additional flags to the controller.

However, it is worth noting that the OCM Add-On framework has a designed way to configure the agent. It would be less surprising to use that rather than controller flags. Also, that way is dynamic --- which may be an advantage in the future. Perhaps we might as well start out using the designed way.

This designed way is explained in https://open-cluster-management.io/developer-guides/addon/#add-your-add-on-agent-supported-configurations . This would involve a AddOnDeploymentConfig or a ConfigMap in the ITS that holds the desired parameters, or an annotation on the ManagedClusterAddon in the ITS that holds the desired parameters (per https://open-cluster-management.io/developer-guides/addon/#values-definition).

In either approach, there is an additional step needed to have a proper interface. The OCM Status Add-On Controller runs in a namespace in the KubeFlex hosting cluster and this namespace is not part of the KubeStellar interface. The ITS also is an implementation detail, not part of the KubeStellar interface. So in either case, some additional definition is needed.

Currently, examples.md says this about how to create an ITS:

kflex create its1 --type vcluster -p ocm

The ocm PostCreateHook takes no parameters for agent log verbosity or client-side self-restraint. We could define such, but remember that a PostCreateHook does not have the concept of default values for parameters; every use would have to supply value for those parameters.

In the near future we hope to wrap this up in Helm chart(s). These do have a concept of default values.

[MikeSpreitzer]

@pdettori
@francostellari

[MikeSpreitzer]

It occurs to me that there is a possible variation on the simple idea of adding a controller flag per agent flag. That is to add one controller flag whose value is all the agent flag settings to apply. Perhaps as a space-separated string. I suggest space separation because commas are already used in some values (e.g., --vmodule) and spaces are not (as far as I know).