RFE - ability to easily add nodes to a config file non-destructively

[Steven Hardy]

It would be nice if you could pass a -c someconfig.yaml, and not teardown any of the existing nodes/undercloud when no --teardown is specfied (e.g have quickstart be idempotent by default).

In particular this would be super useful for new users where you create a minimal environment by default with only two nodes, then you're likely to want to easily add some more later without breaking what you already have.

[John Trowbridge (trown)]

I think the way our ansible roles are structured this should be possible by just using ansible directly with a custom playbook that only ran the role that creates overcloud nodes.

It would be good to make a playbook for that though and document how to use it via quickstart.sh.

We would also want some CI around that (maybe in the quick job) to ensure it stays working.

[Alan Pevec (apevec)]

I tried to run libvirt/setup/overcloud role but current structure doesn't allow it to run standalone:

source ~/.quickstart/bin/activate
export ANSIBLE_CONFIG=~/.quickstart/tripleo-quickstart/ansible.cfg
source ~/.quickstart/tripleo-quickstart/ansible_ssh_env.sh
cat > nodes.yml <<EOF
overcloud_nodes:
  - name: control_0
    flavor: control
  - name: control_1
    flavor: control
  - name: compute_0
    flavor: compute
EOF
cat > add-nodes.yml <<EOF
- name: Add overcloud vms
  hosts: virthost
  gather_facts: yes
  roles:
    - libvirt/setup/overcloud
EOF

ansible-playbook -i virthost, -e @nodes.yml add-nodes.yml

...
TASK [libvirt/setup/overcloud : Ensure volume pool directory exists] ***********
fatal: [virthost]: FAILED! => {"failed": true, "msg": "'libvirt_volume_path' is undefined"}

[Alan Pevec (apevec)]

libvirt/setup role almost worked, it failed at

TASK [setup/undercloud : Generate ssh configuration] ***************************
fatal: [virthost -> localhost]: FAILED! => {"changed": true, "failed": true, "msg": "Aborting, target uses selinux but python bindings (libselinux-python) aren't installed!"}

but vms got created:
 - compute_0 shut off
 - control_0 shut off
 - control_1 shut off

but instackenv.json was not regenerated.

[Alan Pevec (apevec)]

Found one non-idempotency issue when re-running with
  - name: swift_0
    flavor: objectstorage
in the overcloud_nodes:

TASK [setup/overcloud : Attach additional blockdevices to overcloud objectstorage VMs] ***
...
failed: [virthost] (item=[{u'flavor': u'objectstorage', u'name': u'swift_0'}, u'vdd']) => {"changed": true, "cmd": ["virsh", "attach-disk", "--config", "swift_0", "/home/stack/.quickstart/pool/swift_0_vdd.img", "vdd"], "delta": "0:00:00.034526", "end": "2016-12-08 04:01:10.547250", "failed": true, "item": [{"flavor": "objectstorage", "name": "swift_0"}, "vdd"], "rc": 1, "start": "2016-12-08 04:01:10.512724", "stderr": "error: Failed to attach disk\nerror: Requested operation is not valid: target vdd already exists", "stdout": "", "stdout_lines": [], "warnings": []}

[John Trowbridge (trown)]

moved to tripleo launchpad with quickstart tag

This is something we would really like to implement in Pike.

[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