Add additional files to neutron-sanity-check#82
Conversation
neutron-sanity-check expects to be passed all the --config-file/--config-dir options the Neutron services receive. Unfortunately, when we pass in a file/directory that doesn't exist, the script crashes. So we're building the list of existing files/dirs in a shell script and pass only the ones they're present. We could do the same in Ansible, but that would generate a lot of duplicate output and be more confusing to the users.
| tasks: | ||
| - name: Run neutron-sanity-check | ||
| command: neutron-sanity-check --config-file /etc/neutron/neutron.conf | ||
| script: files/neutron-sanity-check '"{{config_files|join(" ")}}" "{{config_dirs|join(" ")}}"' |
There was a problem hiding this comment.
The script expects 2 arguments, you need to remove the single quotes otherwise you'll get an unbound variable $2 error when running the script.
|
So, I've looked at how I'm not exactly sure what is the best way to get the list of options passed to neutron binaries. |
|
Hm, right. So the authoritative place for these is the systemd unit files. Although in HA setup, we're managing some services via pacemaker and I'm not sure if Neutron is one of them. We could try to read this list from the unit files (that's how I built this list manually), but that would be platform-specific (TripleO only supports only RHEL and CentOS so we should be fine for now). A lot of these config files and directories passed to neutron don't actually exist which is why I had to add the shell script. What I tried to do here is to have a default list that can be overridden, but I get your point. So, do you have any ideas on how to proceed with this? |
2 participants
neutron-sanity-check expects to be passed all the --config-file/--config-dir
options the Neutron services receive.
Unfortunately, when we pass in a file/directory that doesn't exist, the script
crashes. So we're building the list of existing files/dirs in a shell script
and pass only the ones they're present.
We could do the same in Ansible, but that would generate a lot of duplicate
output and be more confusing to the users.