[openstack-dev] [kolla] pid=host

Steven Dake (stdake) stdake at cisco.com
Fri Feb 12 15:09:07 UTC 2016


Unfortunately I am in a remodel process atm and unable to test.

It sounds like with qemu without KVM (as in emulated virtualization) the
processes get killed.  With KVM they don't get killed.

I'll add this to the bug tracker, but for our typical use case of "Deploy
OpenStack on bare metal" it seems like Kolla has always worked as is since
Docker 1.6.  What threw this bug into panic mode was the using of
virtualized environments where docker does kill everything.


On 2/9/16, 9:17 AM, "Daniel J Walsh" <dwalsh at redhat.com> wrote:

>Yes I am hearing from different people that this is working fine.  But
>keeping track of this issue in the bugzilla is best.
>I doubt that there was a change in the way docker handles killing
>processes that run in a container when PID=host.
>The way this is coded is to kill all processes in the pid1 cgroup.
>libvirt is supposed to start the VM in a different Cgroup
>which should mean that docker would loose track of the VM process, and
>not be able to kill it.  If this is a new failure, we
>need to establish whether libvirt and the VM end up in the same CGRoup
>or a different one.  And whether or not it is actually
>On 02/08/2016 10:53 PM, Steven Dake (stdake) wrote:
>> Michal,
>> You listed steps to reproduce but it wasn't clear if docker 1.10 kills
>> or keeps them alive from your description.  From our discussion today,
>> sounded as if docker 1.10, docker 1.9, and docker 1.8.2 have different
>> behaviors on this front.  Could you expand?
>> Dan had required to keep the discussion in the bugzilla for tracking
>> purposes.  Would you mind creating a bugzilla account and adding your
>> to the bug?
>> Regards
>> -steve
>> On 2/8/16, 12:15 PM, "Michał Jastrzębski" <inc007 at gmail.com> wrote:
>>> 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) <stdake at 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
>>>> 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
>>>> 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,
>>>> 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
>>>> 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
>>>> which Red Hat can spearhead
>>>> Thoughts and comments welcome.
>>>> Regards
>>>> -steve
>>>> _
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: 
>>>> OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list