RFE - Use an options file for deployment
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
tripleo |
Triaged
|
Wishlist
|
Unassigned |
Bug Description
(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-
might look like the following
---
templates: /home/stack/
timeout: 240
validation_
overcloud_ssh_user: rdo-admins
environment_files:
- templates/
- templates/
- templates/
- templates/
- templates/
- templates/
- templates/
- rdocloud-
- rdocloud-
- rdocloud-
- rdocloud-
- rdocloud-
- rdocloud-
Then whenever you ran 'openstack overcloud deploy' or 'openstack
overcloud update' it would look in the current working directory for
overcloud-
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/
And it would read the environment files (and other settings) from
overcloud-
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-
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-
--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-
openstack overcloud deploy -c overcloud-
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?
Changed in tripleo: | |
status: | New → Triaged |
importance: | Undecided → Wishlist |
milestone: | none → queens-1 |
Changed in tripleo: | |
milestone: | queens-1 → queens-2 |
Changed in tripleo: | |
milestone: | queens-2 → queens-3 |
Changed in tripleo: | |
milestone: | queens-3 → queens-rc1 |
Changed in tripleo: | |
milestone: | queens-rc1 → rocky-1 |
Changed in tripleo: | |
milestone: | rocky-1 → rocky-2 |
Changed in tripleo: | |
milestone: | rocky-2 → rocky-3 |
Changed in tripleo: | |
milestone: | rocky-3 → rocky-rc1 |
Changed in tripleo: | |
milestone: | rocky-rc1 → stein-1 |
Changed in tripleo: | |
milestone: | stein-1 → stein-2 |
Changed in tripleo: | |
milestone: | stein-2 → stein-3 |
Changed in tripleo: | |
milestone: | stein-3 → train-1 |
Changed in tripleo: | |
milestone: | train-1 → train-2 |
Changed in tripleo: | |
milestone: | train-2 → train-3 |
Changed in tripleo: | |
milestone: | train-3 → ussuri-1 |
Changed in tripleo: | |
milestone: | ussuri-1 → ussuri-2 |
Changed in tripleo: | |
milestone: | ussuri-2 → ussuri-3 |
Changed in tripleo: | |
milestone: | ussuri-3 → ussuri-rc3 |
Changed in tripleo: | |
milestone: | ussuri-rc3 → victoria-1 |
Changed in tripleo: | |
milestone: | victoria-1 → victoria-3 |
I agree on this, having an input file instead of several command parameters will help a lot on usability.