[RFE]: Provide a GUI to set --ntp-server, --neutron-network-type etc

[Udi Kalifon]

When deploying from the CLI the user can pass several important parameters such as --libvirt-type, --ntp-server clock.redhat.com, --neutron-network-type, --neutron-tunnel-types... and maybe more.

Finding those parameters in the GUI is very difficult, and another problem is that if you use the CLI and the GUI together - you won't see what was set with the other interface.

We need to better expose these parameters in the GUI and make sure it integrates well so that there won't be a duplication with the CLI.

[Julie Pichon (jpichon)]

Current workarounds, for reference:

- NTP can be defined in a few places, when clicking on the "Edit" pencil for some of the roles, e.g. Controller card - > Services tab -> OS::TripleO::Services::Ntp

- Neutron network type, same thing: "Edit" pencil, Controller node -> Services tab -> OS::TripleO::Services::NeutronCorePlugin -> NeutronNetworkType

- Neutron tunnel type, probably NeutronTypeDrivers in that same Services tab

[Udi Kalifon (ukalifon)]

We also need a GUI for the SSLKey and SSLCertificate fields, otherwise it's impossible to deploy an ssl-ized overcloud. I can't find these parameters even in the services configuration of the roles.

[Julie Pichon (jpichon)]

Udi, would you mind filing the missing SSL parameters as a separate issue? If they don't exist at all this is quite bad and more urgent to fix in my opinion, than the other parameters which are hard to find but do exist somewhere.

[Jiri Tomasek (jtomasek)]

These requriements should be covered by this Ocata spec https://review.openstack.org/#/c/393365/

SSLKey and SSLCertificate parameters are enabled by Enable TLS environment and reside in NestedParameters > Controller > NestedParameters > 0 > NestedParameters > NodeTLSData resource in a resource tree which we get from heat. We don't show parameters of this resource anywhere, but GUI is aware of them.

This problem is going to get resolved by environment parameters listing part of mentioned spec.

[Julie Pichon (jpichon)]

The SSL parameters need to be set by the user (with their own key and certificate) in order to deploy a SSL overcloud successfully though. Is there some kind of workaround we could apply that would be backportable to Newton, until we get the proper fix in Ocata with this spec?

[Jiri Tomasek (jtomasek)]

A workaround is to fill in the parameter values manually in enable-tls.yaml environment file and update the plan with that change

[Julie Pichon (jpichon)]

As far as I know, there isn't really a way to update a plan at the moment. So, create a new plan? Delete and recreate the overcloud plan? Switching back to the CLI isn't ideal in general. I wonder if maybe we could temporarily do something horrible, like hardcoding the two parameters in the Overall Settings so they are configurable from the UI?

[Julie Pichon (jpichon)]

Quite probably just as ugly, I wonder if folks would be open to temporarily make these parameters visible in the default templates, so the UI could pick them up automatically.

[Julie Pichon (jpichon)]

The CLI works around not being able to update a plan by recreating the plan every deploy, since the user needs to specify each option every time anyway.

It looks like an --update-plan-only switch was added as a stopgap to the deploy command recently [1], to avoid having to redeploy. However from the "switching between CLI and web UI" perspective that'd mean making sure to have all the CLI switches set to match whatever was configured in the UI first, so perhaps it is better to simply start with a new plan that has the correct SSL options in, for the workaround in #6.

[1] https://review.openstack.org/#/c/389830/

[Jason E. Rist (jason-rist)]

My understanding is that the --update-plan-only was not meant to be a long term solution.

[Julie Pichon (jpichon)]

I think this can probably be marked as resolved? It's possible to set the parameters including things like the SSL certificate now, without workarounds.

[Liz Blanchard (lblanchard)]

@Udi - Thoughts on surfacing these parameters in an "Overall Network Settings" type view?
https://lizsurette.github.io/OpenStack-Design/tripleo-ui/2-preparation-before-edge-technician-deploys/img/2017-7-24-TripleO-UI_13_PrepWork29.png

[Udi Kalifon (ukalifon)]

Certainly a step in the right direction.

A few comments:

1) I'm not sure where in the templates the ntp is configured. What I'm afraid of is that the user might not fill in a value, and the GUI will replace the default value in the templates with a blank value. We need to check what happens in this case.

2) The base network configuration is selected when the user chooses it from the configuration dialog. We shouldn't duplicate the selection in this dialog as well.

3) I'm not sure in "neutron tunnel types" and "neutron network type" are still relevant. They have been removed from the CLI.

[Emilien Macchi (emilienm)]

This is an automated cleanup. This bug report has been closed because it
is older than 18 months and there is no open code change to fix this.
After this time it is unlikely that the circumstances which lead to
the observed issue can be reproduced.

If you can reproduce the bug, please:
* reopen the bug report (set to status "New")
* AND add the detailed steps to reproduce the issue (if applicable)
* AND leave a comment "CONFIRMED FOR: <RELEASE_NAME>"
  Only still supported release names are valid (FUTURE, PIKE, QUEENS, ROCKY, STEIN).
  Valid example: CONFIRMED FOR: FUTURE