OpenStack Virtual Baremetal Usability Improvements

If you've looked at the OVB repo or docs recently you may notice that there have been some significant changes. This is a good news-good news situation: the changes are backwards compatible and if you use the new configuration method it's much easier to deploy with some of the more advanced options in OVB.

In short, enabling options in OVB now works more as it does in TripleO. Instead of writing one monolithic environment file that has to include all of the appropriate parameters, parameter_defaults, and resource_registry entries, there is a base environment file that includes all the required parameters for a basic OVB deployment. To enable other options, additional environment files can now be passed to the deploy command. For example, passing -e environments/port-security.yaml will allow the use of the Neutron port-security extension instead of the noop firewall driver on the host cloud. There are a number of other environments available, all of which are listed in the environment index. Any number of these can be included, although some are mutually exclusive (passing both the undercloud-floating-existing.yaml and undercloud-floating-none.yaml environments would be nonsense, for example).

Note that parameter and resource_registry resolution is the same as regular Heat. Specifically, the last environment to set a value wins. So if two environments pass the private_net parameter then the value provided in the later file will be respected. I don't know that there is any such duplication in the current environments, but it's something to keep in mind when working with custom environments.

There are a few important details to note:

1. The old env.yaml.example and env-role.yaml.example templates should no longer be used. As I noted, the changes are backwards compatible but these files are now considered deprecated and may be removed at some point in the future. The docs have been updated to reflect this, but any existing automation that uses those files should be updated to use the new base.yaml from the environments directory.
2. Further details about how to deploy advanced environments with the new method can be found in the QuintupleO docs.
3. Some environments have additional parameters that may need to be set. For example, environments/undercloud-floating-existing.yaml includes the parameters undercloud_floating_ip and undercloud_floating_ip_id that are only relevant in deployments that use the environment. In that case, both parameters must be set in order for the environment to work correctly. Some environments include parameters with sane defaults that can be overridden if desired, but don't necessarily need to be.

This change was motivated by some questions I've gotten from people trying to deploy with more advanced configurations. For example, deploying all networks with port-security was non-trivial under the previous monolithic configurations. Now it's as simple as including the all-networks-port-security.yaml environment. It's also much less error-prone than simply uncommenting entries in the example file was. I helped debug a number of environments where the problem turned out to be that someone uncommented a resource_registry entry, but didn't uncomment the resource_registry section key, so Heat saw the entries as part of the parameters section. Hopefully this sort of problem will not happen in the new method.

Overall I think this is a big step forward in the user experience of OVB. Please take a look and let me know any feedback you have about the new system.