yahoo-eng-team team mailing list archive

[Ben Swartzlander <ben@xxxxxxxxxxxxxxxx>]

I think I finally found a solution to this problem. If mount propagation
is enabled before neutron starts creating child processes, then unmount
operation can propagate into the neutron namespaces, eliminating the
issue. On Ubuntu Trusty, all mounts are private by default, but "sudo
mount --make-rshared /" can fix this.

Based on this evidence, I'm going to say that I don't believe this is a
bug in Neutron. Linux mount namespaces are behaving as intended and we
just need to exercise extra care around them.

** Changed in: neutron
       Status: New => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1546723

Title:
  dnsmasq processes inherit system mounts that should not be inherited

Status in neutron:
  Invalid

Bug description:
  See paste [1] - there is list of mounts that each dnsmasq process
  holds. The ones that have "alpha", "betta" and "gamma" words in names
  are ZFS filesystems. And it is impossible to unmount them. In case of
  ZFS it means we cannot "destroy" ZFS filesystems that are in that list
  because it is "busy". To be able to destroy ZFS dataset we need either
  terminate dnsmasq processes or hack them to unmount those mounts.

  It happens when we create dataset first then spawn dnsmasq process.

  Problem was found in Manila project with its new ZFSonLinux share
  driver  [2] running Neutron on same host.

  Tested on Ubuntu Trusty, OpenStack master (Mitaka).

  Expected behaviour: each dnsmasq process should hold only required
  mounts for it not blocking all other while it is alive.

  [1] http://paste.openstack.org/show/487325/

  [2] https://review.openstack.org/#/c/277192/

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1546723/+subscriptions