[Yahoo-eng-team] [Bug 1629133] Re: New neutron subnet pool support breaks multinode testing.
** Changed in: manila Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1629133 Title: New neutron subnet pool support breaks multinode testing. Status in networking-bgpvpn: Fix Released Status in devstack: Fix Released Status in Ironic: Fix Released Status in ironic-python-agent: Fix Released Status in Magnum: Fix Released Status in Manila: Fix Released Status in neutron: Incomplete Status in OpenStack DBaaS (Trove): In Progress Bug description: The new subnet pool support in devstack breaks multinode testing bceause it results in the route for 10.0.0.0/8 being set to via br-ex when the host has interfaces that are actually on 10 nets and that is where we need the routes to go out. Multinode testing is affected because it uses these 10 net addresses to run the vxlan overlays between hosts. For many years devstack-gate has set FIXED_RANGE to ensure that the networks devstack uses do not interfere with the underlying test host's networking. However this setting was completely ignored when setting up the subnet pools. I think the correct way to fix this is to use a much smaller subnet pool range to avoid conflicting with every possible 10.0.0.0/8 network in the wild, possibly by defaulting to the existing FIXED_RANGE information. Using the existing information will help ensure that anyone with networks in 10.0.0.0/8 will continue to work if they have specified a range that doesn't conflict using this variable. In addition to this we need to clearly document what this new stuff in devstack does and how people can work around it should they conflict with the new defaults we end up choosing. I have proposed https://review.openstack.org/379543 which mostly works except it fails one tempest test that apparently depends on this new subnet pool stuff. Specifically the V6 range isn't large enough aiui. To manage notifications about this bug go to: https://bugs.launchpad.net/bgpvpn/+bug/1629133/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1699060] Re: Impossible to define policy rule based on domain ID
** Changed in: manila Importance: Undecided => Wishlist ** Changed in: manila Status: New => Opinion -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1699060 Title: Impossible to define policy rule based on domain ID Status in Cinder: New Status in Glance: New Status in OpenStack Heat: Triaged Status in Manila: Opinion Status in neutron: New Status in OpenStack Compute (nova): Opinion Status in watcher: New Bug description: We have common approach to set rules for each API using policy.json file. And for the moment, it is not possible to use "domain_id" in policy rules, only "project_id" and "user_id". It becomes very important because Keystone API v3 is used more and more. The only service that supports rules with "domain_id" is Keystone itself. As a result we should be able to use following rules: "admin_or_domain_owner": "is_admin:True or domain_id:%(domain_id)s", "domain_owner": "domain_id:%(domain_id)s", like this: "volume:get": "rule:domain_owner", or "volume:get": "rule:admin_or_domain_owner", Right now, we always get 403 error having such rules. Related mail-list thread: https://openstack.nimeyo.com/115438 /openstack-dev-all-policy-rules-for-apis-based-on-domain_id To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1699060/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1546723] Re: dnsmasq processes inherit system mounts that should not be inherited
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 -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1368910] Re: intersphinx requires network access which sometimes fails
** Changed in: manila Status: Fix Committed => Fix Released ** Changed in: manila Milestone: None => juno-rc1 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1368910 Title: intersphinx requires network access which sometimes fails Status in Cinder: In Progress Status in Manila: Fix Released Status in OpenStack Compute (Nova): In Progress Status in The Oslo library incubator: Fix Released Status in python-manilaclient: Fix Committed Bug description: The intersphinx module requires internet access, and periodically causes docs jobs to fail. This module also prevents docs from being built without internet access. Since we don't actually use intersphinx for much (if anything), lets just remove it. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1368910/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
