container stuck restarting on initial deploy is not reconfigured by a subsequent deploy
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
kolla |
Invalid
|
Critical
|
Steven Dake |
Bug Description
I was playing with kolla inside Virtualbox (which lacks nested VT support)
So, the initial kolla-ansible deploy left me with a nova-libvirt that had tried to start (and failed, due to the lack of nested VT) using the kvm default. Log message was something like:
NFO:__main_
INFO:__
INFO:__
INFO:__
INFO:__
INFO:__
INFO:__
Running command: '/usr/sbin/libvirtd —listen'
repeated 10 times on that container
So, then I switched to qemu by editing /etc/kolla/
The config change appeared to get picked up in that 2-3 containers were reported changed, but the nova-libvirt was still not started
Seems like the ansible doesn't detect that corner case of an initially failed container start and deal with it on reconfig? vs having to manually docker kill it and then run the kolla-ansible
(Note: I'll try to reproduce cleanly and validate this. I had enough in flight on this that it may be more complicated than that)
Thanks Chris. I have seen this same behavior many times and reporting this as confirmed. It has been reported in the past as well. I'm not sure it can be fixed in an automated way for Liberty because it may require significant changes to the playbooks. After discussion with inc0, we think it will be solvable in Mitaka via a "kolla-ansible reconfigure" feature which could docker exec rm the config once lock file and restart containers that have configuration changes associated with them.
I think a backport may be difficult given the rate of change in Mitaka playbooks, but anything is possible :)
Regards,
-steve