[Yahoo-eng-team] [Bug 1821357] [NEW] VRRP vip on VM not reachable from other network on DVR setup
Public bug reported: Hi. We are using OpenStack Queens with DVR and have the following problem: We have a VRRP setup (OpenSense firewalls) on VMs. The vip is reachable from alle other VMs in the same network, but not from VMs in different networks. Both OpenSense VMs are reachable from the other network. So, routing in general between the two networks works fine, but we cannot reach the vip from the other network. Port Security is deactivated. It does work if the VRRP master VM is on the same compute node as the test VM trying to reach it. Further investigation shows that when trying to ping the vip, the ICMP message reaches the router interface on the compute node where the VM sending it is located. But a ovs-tcpdump on patch-int port shows that there is no traffic tunneled between the hosts. So, if the VRRP master with the vip is on the same node as the VM trying to reach it, it receives the ping and answers. If it is on a different node, we can observe an arp request from the router interface only on the node where the VM sending the ping is located. This arp request is unanswered. It seems to us that this is a bug in Neutron. Yours David ** Affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1821357 Title: VRRP vip on VM not reachable from other network on DVR setup Status in neutron: New Bug description: Hi. We are using OpenStack Queens with DVR and have the following problem: We have a VRRP setup (OpenSense firewalls) on VMs. The vip is reachable from alle other VMs in the same network, but not from VMs in different networks. Both OpenSense VMs are reachable from the other network. So, routing in general between the two networks works fine, but we cannot reach the vip from the other network. Port Security is deactivated. It does work if the VRRP master VM is on the same compute node as the test VM trying to reach it. Further investigation shows that when trying to ping the vip, the ICMP message reaches the router interface on the compute node where the VM sending it is located. But a ovs-tcpdump on patch-int port shows that there is no traffic tunneled between the hosts. So, if the VRRP master with the vip is on the same node as the VM trying to reach it, it receives the ping and answers. If it is on a different node, we can observe an arp request from the router interface only on the node where the VM sending the ping is located. This arp request is unanswered. It seems to us that this is a bug in Neutron. Yours David To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1821357/+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 1815728] [NEW] Can delete port attached to VM without Nova noticing
Public bug reported: In the Rocky release it still possible to delete a port that is attached to a VM as primary network interface. Nova doesn't even seem to notice when this happens. Shouldn't there be any kind of precaution form Neutron's side? Reproduce: $ openstack port create ... $ openstack server create --port ... $ openstack port delete ... $ openstack server show ... ** Affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1815728 Title: Can delete port attached to VM without Nova noticing Status in neutron: New Bug description: In the Rocky release it still possible to delete a port that is attached to a VM as primary network interface. Nova doesn't even seem to notice when this happens. Shouldn't there be any kind of precaution form Neutron's side? Reproduce: $ openstack port create ... $ openstack server create --port ... $ openstack port delete ... $ openstack server show ... To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1815728/+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 1815594] [NEW] update-member throws 404
Public bug reported: Hi, I'm using PackStack with OpenStack Rocky release. When creating an image in project1 and adding project2 as a member to it, project2 has pending status for the image. That's correct so far. When switching to a user from project2 (_member_ role in that project) and trying to do a glance image update, it fails with a 404. The image cannot be found. It works neither with OSC nor with glanceclient, so it might be a bug in Glance itself. # glance-api --version 17.0.0 # glance --version 2.13.1 # openstack --version openstack 3.16.2 ** Affects: glance Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1815594 Title: update-member throws 404 Status in Glance: New Bug description: Hi, I'm using PackStack with OpenStack Rocky release. When creating an image in project1 and adding project2 as a member to it, project2 has pending status for the image. That's correct so far. When switching to a user from project2 (_member_ role in that project) and trying to do a glance image update, it fails with a 404. The image cannot be found. It works neither with OSC nor with glanceclient, so it might be a bug in Glance itself. # glance-api --version 17.0.0 # glance --version 2.13.1 # openstack --version openstack 3.16.2 To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1815594/+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 1793351] [NEW] CONF.libvirt.snapshot_image_format does not always default to format of source image
Public bug reported: It seems to be intended, that CONF.libvirt.snapshot_image_format defaults to the format of the source image. That is also what the docs say. See for example https://docs.openstack.org/nova/latest/configuration/sample-config.html If the format of the source image is raw, the raw image is only used as a backing file with a qcow2 overlay. So find_disk() from nova's libvirt utils will return the overlay file and qcow2 as a format. What we want to use here is the format of the backing file. ** Affects: nova Importance: Undecided Status: New -- 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/1793351 Title: CONF.libvirt.snapshot_image_format does not always default to format of source image Status in OpenStack Compute (nova): New Bug description: It seems to be intended, that CONF.libvirt.snapshot_image_format defaults to the format of the source image. That is also what the docs say. See for example https://docs.openstack.org/nova/latest/configuration/sample-config.html If the format of the source image is raw, the raw image is only used as a backing file with a qcow2 overlay. So find_disk() from nova's libvirt utils will return the overlay file and qcow2 as a format. What we want to use here is the format of the backing file. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1793351/+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 1766257] [NEW] Image Service API v2 (CURRENT) broken link
Public bug reported: This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [x] This doc is inaccurate in this way: broken link to http://docs.openstack.org/developer/glance/tasks.html --- Release: 16.0.0.0rc2.dev123 on 'Wed Apr 18 12:08:04 2018, commit c6376ea' SHA: Source: https://git.openstack.org/cgit/openstack/glance/tree/api-ref/source/v2/index.rst URL: https://developer.openstack.org/api-ref/image/v2/index.html ** Affects: glance Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1766257 Title: Image Service API v2 (CURRENT) broken link Status in Glance: New Bug description: This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [x] This doc is inaccurate in this way: broken link to http://docs.openstack.org/developer/glance/tasks.html --- Release: 16.0.0.0rc2.dev123 on 'Wed Apr 18 12:08:04 2018, commit c6376ea' SHA: Source: https://git.openstack.org/cgit/openstack/glance/tree/api-ref/source/v2/index.rst URL: https://developer.openstack.org/api-ref/image/v2/index.html To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1766257/+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 1727941] [NEW] ML2 plug-in in neutron - Link to OpenStack Admin Guide does not make sense anymore
Public bug reported: This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [x] This doc is inaccurate in this way: There is a link to the OpenStack Admin Guide for more information on provider networks and project networks. This is an old link (with a wrong anchor), which will eventually lead to the OpenStack Networking page that is linked in the same line. Make a long story short: I would like to delete that link, since it is useless. It is in paragraph "Project network types". The link to https://docs.openstack.org/admin-guide/networking-adv-features.html #provider-networks Yours David --- Release: 11.0.2.dev40 on 2017-10-25 21:29 SHA: 2cafbe9e06909d8e9710ff57da6b288f56322901 Source: https://git.openstack.org/cgit/openstack/neutron/tree/doc/source/admin/config-ml2.rst URL: https://docs.openstack.org/neutron/pike/admin/config-ml2.html ** Affects: neutron Importance: Undecided Assignee: David Rabel (rabel-b1) Status: New ** Tags: doc ** Changed in: neutron Assignee: (unassigned) => David Rabel (rabel-b1) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1727941 Title: ML2 plug-in in neutron - Link to OpenStack Admin Guide does not make sense anymore Status in neutron: New Bug description: This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [x] This doc is inaccurate in this way: There is a link to the OpenStack Admin Guide for more information on provider networks and project networks. This is an old link (with a wrong anchor), which will eventually lead to the OpenStack Networking page that is linked in the same line. Make a long story short: I would like to delete that link, since it is useless. It is in paragraph "Project network types". The link to https://docs.openstack.org/admin-guide/networking-adv-features.html #provider-networks Yours David --- Release: 11.0.2.dev40 on 2017-10-25 21:29 SHA: 2cafbe9e06909d8e9710ff57da6b288f56322901 Source: https://git.openstack.org/cgit/openstack/neutron/tree/doc/source/admin/config-ml2.rst URL: https://docs.openstack.org/neutron/pike/admin/config-ml2.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1727941/+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 1489059] Re: "db type could not be determined" running py34
** Also affects: python-openstackclient Importance: Undecided Status: New ** Changed in: python-openstackclient Assignee: (unassigned) => David Rabel (rabel-b1) ** No longer affects: python-openstackclient -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1489059 Title: "db type could not be determined" running py34 Status in Aodh: Fix Released Status in Barbican: Fix Released Status in Bareon: Fix Released Status in Cinder: Fix Released Status in cloudkitty: Fix Released Status in Fuel for OpenStack: In Progress Status in Fuel for OpenStack mitaka series: Won't Fix Status in Fuel for OpenStack newton series: In Progress Status in Glance: Fix Released Status in hacking: Fix Released Status in heat: Fix Released Status in Ironic: Fix Released Status in ironic-lib: Fix Committed Status in OpenStack Identity (keystone): Fix Released Status in keystoneauth: Fix Released Status in keystonemiddleware: Fix Released Status in kolla: Fix Released Status in Manila: Fix Released Status in networking-midonet: Fix Released Status in networking-odl: Fix Released Status in networking-ofagent: Fix Released Status in neutron: Fix Released Status in Glance Client: Fix Released Status in python-keystoneclient: Fix Released Status in python-muranoclient: Fix Released Status in python-solumclient: Fix Released Status in python-swiftclient: In Progress Status in Rally: Fix Released Status in Sahara: Fix Released Status in OpenStack Search (Searchlight): Fix Released Status in senlin: Fix Released Status in tap-as-a-service: Fix Released Status in tempest: Fix Released Status in zaqar: Fix Released Status in python-ironicclient package in Ubuntu: Fix Committed Bug description: When running tox for the first time, the py34 execution fails with an error saying "db type could not be determined". This issue is know to be caused when the run of py27 preceeds py34 and can be solved erasing the .testrepository and running "tox -e py34" first of all. To manage notifications about this bug go to: https://bugs.launchpad.net/aodh/+bug/1489059/+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
