UI config is overwritten on undercloud upgrade

[Julie Pichon]

Following the information at http://tripleo.org/installation/installation.html#updating-undercloud-components, I updated my Newton undercloud with "openstack undercloud upgrade". It worked well, except the settings I had set manually at /var/www/openstack-tripleo-ui/dist/tripleo_ui_config.js were overwritten, leading to the UI becoming unusable (can't log in or access services).

This is happening because we are creating the file with Puppet at https://github.com/openstack/puppet-tripleo/blob/15c7d4/manifests/ui.pp#L109. This is probably the correct behaviour when configuration is managed by puppet like this, and that way when new settings etc are required with new versions they will be set up correctly when upgrading.

It is however causing issues when URLs need to be overridden, which is currently the case when e.g. using the UI in a virtualised environment (until https://blueprints.launchpad.net/tripleo/+spec/enable-communication-ui-undercloud is implemented, tunnelling is required and the URLs in that file need to be adjusted.)

It's not entirely clear to me if this requires only a new setting in the puppet configuration, or if we also need a new setting in undercloud.conf as well. I think perhaps it makes sense that if the existing "undercloud_hostname" parameter in undercloud.conf is set, then we use it to create the service URLs with that hostname in tripleo_ui_config.js rather than take them from the catalogue.

[Steven Hardy (shardy)]

So I think puppet overwriting the config file is expected, any file managed by puppet should not be manually modified.

I think you'll need to modify the puppet manifest which manages the UI config to do what you need:

https://github.com/openstack/puppet-tripleo/blob/master/manifests/ui.pp

Then you can pass data to influence the configuration via a hieradata overrides file:

https://github.com/openstack/instack-undercloud/blob/master/instack_undercloud/undercloud.py#L231

then you can have a file e.g my_overrides.yaml specified in your undercloud.conf which contains hiera key/value pairs, e.g

  tripleo::ui::someconfig: foo

You might also be able to modify the manifest to do what you need (e.g I assume the reason you're configuring that manually is puppet doesn't configure the file to point at keystone correctly?)

[Steven Hardy (shardy)]

In the last comment above I mean you may be able to use existing undercloud.conf data wired in to the manifest to do what you need, vs relying on hieradata overrides (which are supposed to be for special cases, which I'm assuming a working UI is not ;)

[Julie Pichon (jpichon)]

Thank you for the information and links, Steven!

From further discussions on IRC, particularly with jaosorior, using the undercloud_hostname parameter may not be accurate. For instance, if the undercloud was deployed with SSL, undercloud_public_vip and undercloud_admin_vip may need to be taken into account instead.

[Dan Trainor (dtrainor)]

As discussed, there are still very good use cases for both creating a default tripleo_ui_config.js configuration file using undercloud_public_vip and having this file be editable by hand.

Take the example of running a deployment in OVB. In this case, the Undercloud may use the value of undercloud_public_vip in tripleo_ui_config.js but the Undercloud instance is in a tenant network that provides it a real public IP via NAT. In its default case, both the keystone endpoints and the contents of tripleo_ui_config.js would instruct the client (the UI in the browser) to use some sort of locally-accessible or resolvable hostname/IP that's not available from the NAT'd tenant network, and thus not available to the client (the UI in the browser). In this case, it would be beneficial to populate tripleo_ui_config.js with the public NAT address that represents the Undercloud instance.

In the case where NAT is not used, then the defaults as they are right now would suffice.

Since we're using a File resource in https://github.com/openstack/puppet-tripleo/blob/master/manifests/ui.pp, I think we should use a 'replace => no' on the resource so that the file can be generated with default values upon installation, but if there are any administrative changes to this file, its contents is not squashed during an update/upgrade.

We were concerned that there was a purge_config setting for the ui puppet class, but this only seems to apply to data covered by the apache class. I think we're ok using replace => no and documenting any additional changes made to tripleo_ui_config.pp that would apply after an update/upgrade.

[Julie Pichon (jpichon)]

This sounds reasonable to me. Testing a little, "replace => no" works nicely in both undercloud re-install and upgrade contexts, so I propose to use this and be careful about documenting changes to the config file for upgrades in the release notes. If there are a lot of changes and/or this is causing more issues than it resolves, we can revisit then.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/388592

[Julie Pichon (jpichon)]

To summarise the discussion on the patch, the "persist" approach is not appropriate, as Puppet should be managing the config file including updates (as is the case for every other TripleO service).

We'll likely need to fix bug 1649997 along the way.

[Julie Pichon (jpichon)]

This is important and needs to be backported, but unfortunately I haven't had a chance to look into it more closely yet. Unassigning myself to give space to others who might want to work on it in the meantime.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Julie Pichon (<email address hidden>) on branch: master
Review: https://review.openstack.org/388592

[Alex Schultz (alex-schultz)]

I'm closing this as won't fix as this is by design. the UI config should be handled by whatever mechanism the undercloud uses for install/updates/upgrades so this may change in the future but for now this is expected.

[Julie Pichon (jpichon)]

Yes, this bug should probably be renamed to something like "Allow users to set their own UI config endpoints." - or if it's already possible via puppet magic, document it.