| @tcervi:matrix.org | Lucas de Ataides: about your [fix](https://review.opendev.org/c/starlingx/openstack-armada-app/+/892707) suggestion for [bug/2032980](https://bugs.launchpad.net/starlingx/+bug/2032980), apparently there is an opportunity to enhance the horizon helm chart templates in openstack/openstack-helm and give it back to the community (like we use to do whenever we see possible enhancements for those openstack helm charts). | 20:57 |
|---|---|---|
| I'm personally not a big supporter of hard coded paths like the one in [horizon/templates/deployment.yaml](https://github.com/openstack/openstack-helm/blob/23877233063672d71c13313e29ce414bafcaad62/horizon/templates/deployment.yaml) | ||
| As peer the comments on your code proposal, we have the option of adding a new values.yaml key to make this path configurable. This is something that is definitely worth of submitting upstream 😁 | ||
| But then, lutimura brought the point that we can customize this path for stx-openstack via plugins, instead of the static-overrides. I would say that I tend to defend the use of static-overrides in this case, but we could use this chat to discuss about it | ||
| @tcervi:matrix.org | > <@tcervi:matrix.org> Lucas de Ataides: about your [fix](https://review.opendev.org/c/starlingx/openstack-armada-app/+/892707) suggestion for [bug/2032980](https://bugs.launchpad.net/starlingx/+bug/2032980), apparently there is an opportunity to enhance the horizon helm chart templates in openstack/openstack-helm and give it back to the community (like we use to do whenever we see possible enhancements for those openstack helm charts). | 20:59 |
| > | ||
| > I'm personally not a big supporter of hard coded paths like the one in [horizon/templates/deployment.yaml](https://github.com/openstack/openstack-helm/blob/23877233063672d71c13313e29ce414bafcaad62/horizon/templates/deployment.yaml) | ||
| > As peer the comments on your code proposal, we have the option of adding a new values.yaml key to make this path configurable. This is something that is definitely worth of submitting upstream 😁 | ||
| > | ||
| > But then, lutimura brought the point that we can customize this path for stx-openstack via plugins, instead of the static-overrides. I would say that I tend to defend the use of static-overrides in this case, but we could use this chat to discuss about it | ||
| I understand lutimura's point, since we would usually make use of static-overrides to configure default values that users would have easy access via user helm overrides. | ||
| The app cert path does not seem to be a kind of customization that users would actually need to override, so that is probably why he proposes to contain all HTTPS related configs inside the plugin | ||
| @lutimura:matrix.org | You guys pretty much summed it up 😅 | 23:32 |
| Having things _helm overridable_ is always desirable from a user's perspective. However, I'm afraid that we already have a solution in place and that we could use to encompass this deployment spec. If you take a look at this patch, [0010-Remove-TLS-from-openstack-services.patch](https://opendev.org/starlingx/openstack-armada-app/src/branch/master/openstack-helm/debian/deb_folder/patches/0010-Remove-TLS-from-openstack-services.patch#L1823-L1827), you will see that it already patches multiple REQUEST_CA_BUNDLEs, just like Lucas de Ataides did in his review. | ||
| So, since we already have static overrides that change OPENSTACK_SSL_CACERT to our desired value, as tcervi pointed out, I think we only need to update the existing patch to also change Horizon's REQUEST_CA_BUNDLE. | ||
| What do you guys think? | ||
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!