RFE - Use an options file for deployment

(copy/paste - email from Graeme Gillies):

So in general the philosophy for operations is, command line arguments
are perfectly fine for a few different things

1) Once off tasks (I wish to create an instance quickly using the
command line)
2) Simple systems (I want to list files in a directory with special
switches, so I use command line arguments to ls)
3) Overwriting default or configured settings once off (e.g. if I want
to run puppet with all settings from puppet.conf, but change the
environment, I'll run puppet agent --test --environment different)

The 'openstack overcloud XXX' commands (deploy, update) *don't* fit this
pattern yet heavily rely on command line options. This is why operators
constantly run into these issues, because we don't expect to have to
commit command line options to memory, because our philosophy is they
are persistent configuration items for the environment, not fitting into
the use cases above.

What we should be doing is forcing our 'openstack overcloud' commands
out from command line options altogether. What I am thinking is we have
it work like this

You create a file called overcloud-settings.yaml (or something) which
might look like the following

---
templates: /home/stack/rdocloud-tripleo/overcloud/templates
timeout: 240
validation_warnings: fatal
overcloud_ssh_user: rdo-admins
environment_files:
  - templates/environments/puppet-pacemaker.yaml
  - templates/environments/network-isolation.yaml
  - templates/environments/network-management.yaml
  - templates/environments/ips-from-pool-all.yaml
  - templates/environments/storage-environment.yaml
  - templates/environments/monitoring-environment.yaml
  - templates/environments/logging-environment.yaml
  - rdocloud-host-definitions.yaml
  - rdocloud-storage-environment.yaml
  - rdocloud-network-environment.yaml
  - rdocloud-customisations.yaml
  - rdocloud-opstools-params.yaml
  - rdocloud-roles-data.yaml

Then whenever you ran 'openstack overcloud deploy' or 'openstack
overcloud update' it would look in the current working directory for
overcloud-settings.yaml and load in the config from there. No more
people forgetting to add environment files.

You can still keep the command line switches, for once off tasks. For
example with the file above, lets say I wish to increase the timeout for
1 stack update only as I think it will take longer for some reason. I
could do

openstack overcloud deploy --timeout 360

And all other settings would be used from the file. Likewise, when we
have tasks (like major upgrades) where we require people to include
extra environment files once off, we can get them to do

openstack overcloud deploy -e
templates/environments/upgrades/major-upgrade-whatever-step1.yaml

And it would read the environment files (and other settings) from
overcloud-settings.yaml and append the major-upgrade-whatever-step1.yaml
to the end of the list.

Another use case would be if I am an operator or developer hacking on
templates and want to test my hacked templates once off, I could do

openstack overcloud deploy --templates gg-hacked-templates

and it would use my templates dir, but all other settings from the file.

Finally, this would also allow us to do another workflow which is better
merging and synchronization of multiple environments in the one git
repo. In the typical case for stage/prod, we can have all the templates
and customisations for both environments in the one git repo and do
something like

openstack overcloud deploy -c overcloud-settings-stage.yaml

To differentiate between using the settings file for staging vs
production. This would massively improve usability from our perspective,
combined with the options above, it would allow me to do something like

openstack overcloud deploy -c overcloud-settings-rdo-cloud-stage.yaml
--templates gg-hacked-templates

To test my hacked template work on our staging environment without
having to remember the spaghetti mess of command line options I need.

Also for multiple overcloud environments people could do

openstack overcloud deploy -c overcloud-settings-phx2.yaml
openstack overcloud deploy -c overcloud-settings-rdu2.yaml

They would be run on different underclouds, but keeping the work in the
same git repo ensures that both environments use identical templates and
other configurations.

If we implemented this and pushed all documentation to reference it as
the main way of using TripleO, I think you would find it improves
usability by a *massive* amount.

Thoughts?