[operator] convert operator (and hence ConfigMap) settings to k8s standard camelCase

[jmazzitelli]

The Operator SDK will, by default, convert all settings (including those in camelCase) in the CR to snake_case. This caused problems early on, so what we did was to define all of the Kiali CR settings in "snake_case" format.

This, however, caused further problems because some of the Kiali CR settings are k8s yaml (for example, see the affinity settings) - those were converted to snake_case which we then had to play games in the ansible playbook to convert back to camelCase.

The Operator SDK has just recently introduced a new configuration setting in watches.yaml that lets you turn off this snake_case automatic conversion. I think we should consider using that and switching Kiali CR to define its settings using the k8s standard yaml which is camelCase. Because the Kiali CR settings are copied almost verbatim to the ConfigMap, it means server side changes will need to be made because it loads in the ConfigMap.

However, we cannot do this until we move project and downstream product operators to the new SDK that has this feature - and that SDK release is not yet available to us. I am created this issue to keep an eye on this for the future.

See:

• SDK issue: [ansible] CR variables converted to snake_case when passed to playbook operator-framework/operator-sdk#1770
• SDK PR: Make Ansible Operator parameter case conversion optional operator-framework/operator-sdk#3245

This is now supported in watches.yaml:

snakeCaseParameters: false

[jmazzitelli]

This is in SDK 1.0, so we could make this change when we move to that. See: #2983

[jshaughn]

Would this change break compatibility with anything/everything?

[jmazzitelli]

It would break existing customer CRs.

It will probably also affect the SM operator because it creates Kiali CRs with snake_case (for example, it writes spec.deployment.accessible_namespaces -- it would need to create spec.deployment.accessibleNamespaces). So we would need the SM operator to change how it creates the Kiali CR.

I don't think it will break existing ConfigMaps because even if we keep the snake_case settings intact in there, they will simply be ignored - the new camelCase ones would be added by the operator and those would be used. So it is probably not a big deal for ConfigMaps, but of course, I could be missing something.

But for sure existing CRs would break, unless we do some reverse conversion OURSELVES to go the other way -- snake_case to camelCase -- in the ansible playbooks. That would just be annoying and defeat the purpose of this issue (which is to make the coding less complicated in the operator). So if we need to perform some conversion code to support the deprecated snake_case, then I say we don't do anything and just keep using snake_case for the duration of the life of the project.

So this is not an issue to take lightly - it will have ramifications if we do this.

[jmazzitelli]

This would introduce too many changes - including non-backward compat changes (unless we play games to support BOTH camelCase AND snake_case - and that would just make things WORSE not better for maintenance). So let's close this without doing anything. We can keep snake_case settings - it's not a big deal.