Hey, So quick steps to reproduce this:
0. install docker 1.10 1. Deploy kolla 2. Run VM 3. On compute host - ps aux | grep qemu, should show your vm process 4. docker rm -f nova_libvirt 5. ps aux | grep qemu should still show running vm 6. re-deploy nova_libvirt 7. docker exec -it nova_libvirt virsh list - should show running vm Cheers, Michal On 8 February 2016 at 07:32, Steven Dake (stdake) <std...@cisco.com> wrote: > Hey folks, > > I know we have been through some changes with how pid=host works. I'd like > to get to the bottom of this, so we can either add the features we need to > docker, or say "all is good". > > Here is the last quote from this bugzilla where Red Hat in general is > interested in the same behavior as the Kolla team has. They have many > people embedded in the Docker and Kubernetes communities, so it may make > sense to let them do the work there :) > > https://bugzilla.redhat.com/show_bug.cgi?id=1302807 > > Mrunal Patel 2016-02-08 06:10:15 EST > > docker tracks the pids in a container using cgroups and hence all processes > are killed even though we use pid=host. I believe we had probably prompted > them to add this behavior in the first place. > > > This statement appears at odds with what was tested on IRC a few days back > with docker 1.10. It is possible docker 1.10 had a regression here, in > which case if they fix it, we will be back to a dead VM during libvirt > upgrade which we don’t want. > > Can folks that tested this weigh in on the testing that was done on that > bugzilla with distro type, docker version, docker-py version, and results. > Unfortunately you will have to create a Red Hat bugzilla account, but if you > don't wish to do that, please send the information on list after reviewing > the bugzilla and I'll submit it on your behalf. > > The outcomes I would be happy with is: > > * docker will never change the semantics of host=pid mode for killing child > processes > > * Or alternatively docker will add a feature such as host=pidnochildkill > which Red Hat can spearhead > > Thoughts and comments welcome. > > Regards > > -steve > > > > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev