remap osm-arc chart values to osm oss chart values

[michelleN]

The arc extension will pass in a set of Azure specific values related to proxy (and potentially other values later on) at the time that a user installs the osm arc extension on their cluster. This happens essentially via a helm install with the osm-arc chart. You can think of the arc team is trying to do as helm install <osm-arc-chart> --set Azure.httpProxy="something". The osm-arc chart installs the osm chart as a dependency( aka child) meaning it can override values of the child chart. The osm chart is where the proxy configuration is exposed via certain values. For example, one of the proxy settings in the osm chart is called OpenServiceMesh.fluentBit.httpProxy. We want to be able to set the value of Azure.httpProxy to OpenServiceMesh.fluentBit.httpProxy at install time.

Currently, there is not a clean solution for this:

• Moving these values both in the open source osm chart and the osm-arc chart to the Global key in the values files is 1) not a convenient solution for either project and doesn't clearly make sense for the oss chart 2) Not a solution that makes sense for the arc team as they plan to add more Azure specific values and don't want to dirty the Global key in arc extension's chart. PoC & further explanation here.
• We could use a Helm's post rendering functionality and kustomize or a custom bash script to overwrite the original templates that get rendered. This is not functionality that the arc team has at the moment and would require the arc team to enable usage of a post-renderer thereby adding an additional tool/dependency to the toolchain. This is also a somewhat brittle solution as it relies on keeping up pretty manually with any changes in the osm chart templates thereby putting extra work on the team. PoC here.

What we really need is something that is referred to in the Helm community as export-values functionality described here. There is also a open PR for the feature in the Helm repo here. It has been open for about a year now, so the next step on our part would be to engage with the Helm community to see how we can move this work along.

[sozercan]

@michelleN @SanyaKochhar can this be closed without need for log analytics?