[Yahoo-eng-team] [Bug 1774363] Re: Instance is of no use during "shelve-offloading" operation, when nova-conductor is stopped
** Changed in: nova Status: Invalid => 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/1774363 Title: Instance is of no use during "shelve-offloading" operation, when nova- conductor is stopped Status in OpenStack Compute (nova): New Bug description: During shelve-offloading operation if nova-conductor is stopped, the instance stuck forever in "SHELVED" state and task state of instance stuck in "SHELVING_OFFLOADING" state. After restarting the nova-conductor service, the state of instance does not change to "SHELVE_OFFLOADED" from "SHELVED" and the task state remains in "SHELVING_OFFLOADING" state. In this particular state, the instance is of no use because an instance cannot shelve, unshelve and shelve-offload. Source code should be modified to reset the state of instance. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1774363/+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 2049624] [NEW] vpnaas problem --- strongswan on rocky 9
Public bug reported: It seems like this is written exclusively for some dist.. On rocky, it's named strongswan just like in the man page, and it uses /etc/strongswan So setting: [strongswan] default_config_area = /etc/strongswan/strongswan.d should be enough according to the configuration, but there are some issues: 1. Configuration is copied with cp -a and thus still owned by root 2. It seems it doesn't even attempt to put the configuration in the right path -- i patched this manually nd got error that a normal run doesn't get (ie permission denied for the temporary file) Why not ask the binary? strongswan --confdir /etc/strongswan Or set the paths using the environment variables documented? ** 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/2049624 Title: vpnaas problem --- strongswan on rocky 9 Status in neutron: New Bug description: It seems like this is written exclusively for some dist.. On rocky, it's named strongswan just like in the man page, and it uses /etc/strongswan So setting: [strongswan] default_config_area = /etc/strongswan/strongswan.d should be enough according to the configuration, but there are some issues: 1. Configuration is copied with cp -a and thus still owned by root 2. It seems it doesn't even attempt to put the configuration in the right path -- i patched this manually nd got error that a normal run doesn't get (ie permission denied for the temporary file) Why not ask the binary? strongswan --confdir /etc/strongswan Or set the paths using the environment variables documented? To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2049624/+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 1815762] [NEW] you can end up in a state where qvo* interfaces aren't owned by ovs which results in a dangling connection
Public bug reported:
While upgrading to rocky, we ended up with a broken openvswitch
infrastructure and moved back to the old openvswitch.
We ended up with new machines working, old machines didn't and it took a
while to realize that we had qvo* interfaces that not only wasn't
plugged but also wasn't owned by ovs-system - basically the virtual
equivalent of forgetting to plug in the cable ;)
This was quickly addressed by running this bash-ism on all nodes:
for x in `ip a |grep qvo |grep @qvb |grep -v ovs-system | awk '{ print $2 '}` ;
do y=${x%%"@"*} && ip link delete $y ; done ; docker restart nova_compute
However, nova could pretty easily sanity check this =)
** 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/1815762
Title:
you can end up in a state where qvo* interfaces aren't owned by ovs
which results in a dangling connection
Status in OpenStack Compute (nova):
New
Bug description:
While upgrading to rocky, we ended up with a broken openvswitch
infrastructure and moved back to the old openvswitch.
We ended up with new machines working, old machines didn't and it took
a while to realize that we had qvo* interfaces that not only wasn't
plugged but also wasn't owned by ovs-system - basically the virtual
equivalent of forgetting to plug in the cable ;)
This was quickly addressed by running this bash-ism on all nodes:
for x in `ip a |grep qvo |grep @qvb |grep -v ovs-system | awk '{ print $2 '}`
; do y=${x%%"@"*} && ip link delete $y ; done ; docker restart nova_compute
However, nova could pretty easily sanity check this =)
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1815762/+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 1744101] [NEW] vxlan interfaces doesn't get MTU
Public bug reported: When vxlans are created, f.ex. via ensure_vxlan in neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py - no mtu is assigned. This explains why we get vxlan interfaces with 1500 byte mtu even-though neutron has been instructed to use 9000 bytes mtu. The function called: def add_vxlan(self, name, vni, group=None, dev=None, ttl=None, tos=None, local=None, srcport=None, dstport=None, proxy=False): cmd = ['add', name, 'type', 'vxlan', 'id', vni] ... Creates the interface, and from what I understand mtu should be between 'add' and 'type'. I have been unable to find any other place where the mtu would be propagated to the vxlan interface and our tests indicate that it never happens. The problem is that this causes the bridge to set it self to the lower mtu and... noone is happy =) This is on: git describe 11.0.2-8-g7fd30cb (stable/pike) ** 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/1744101 Title: vxlan interfaces doesn't get MTU Status in neutron: New Bug description: When vxlans are created, f.ex. via ensure_vxlan in neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py - no mtu is assigned. This explains why we get vxlan interfaces with 1500 byte mtu even- though neutron has been instructed to use 9000 bytes mtu. The function called: def add_vxlan(self, name, vni, group=None, dev=None, ttl=None, tos=None, local=None, srcport=None, dstport=None, proxy=False): cmd = ['add', name, 'type', 'vxlan', 'id', vni] ... Creates the interface, and from what I understand mtu should be between 'add' and 'type'. I have been unable to find any other place where the mtu would be propagated to the vxlan interface and our tests indicate that it never happens. The problem is that this causes the bridge to set it self to the lower mtu and... noone is happy =) This is on: git describe 11.0.2-8-g7fd30cb (stable/pike) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1744101/+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 1745150] [NEW] neutron doesn't set MTU on ovs
Public bug reported: If you run neutron with OVS it doesn't honor MTU values, which is a issue if you host external environments that needs to communicate with other entities that f.ex. have PMTU disabled as a security measure... Another issue is that the MTU difference happens on a L2 bridge and packets will thus be dropped on the floor and noone will clean up the mess =) Looking at: http://docs.openvswitch.org/en/latest/faq/issues/ Which states: Q: How can I configure the bridge internal interface MTU? Why does Open vSwitch keep changing internal ports MTU? ... ovs-vsctl set int br0 mtu_request=1450 ... --- I can find no reference to this happening anywhere in the code - every where i've looked MTU seems to have been completely ignored. We've been trying to migrated away from OVS due to this, but it's a bit more complex - we found the issue on linuxbridging and could mitigate it, see https://bugs.launchpad.net/neutron/+bug/1744101 ** 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/1745150 Title: neutron doesn't set MTU on ovs Status in neutron: New Bug description: If you run neutron with OVS it doesn't honor MTU values, which is a issue if you host external environments that needs to communicate with other entities that f.ex. have PMTU disabled as a security measure... Another issue is that the MTU difference happens on a L2 bridge and packets will thus be dropped on the floor and noone will clean up the mess =) Looking at: http://docs.openvswitch.org/en/latest/faq/issues/ Which states: Q: How can I configure the bridge internal interface MTU? Why does Open vSwitch keep changing internal ports MTU? ... ovs-vsctl set int br0 mtu_request=1450 ... --- I can find no reference to this happening anywhere in the code - every where i've looked MTU seems to have been completely ignored. We've been trying to migrated away from OVS due to this, but it's a bit more complex - we found the issue on linuxbridging and could mitigate it, see https://bugs.launchpad.net/neutron/+bug/1744101 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1745150/+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 1749667] [NEW] neutron doesn't correctly handle unknown protocols and should whitelist known and handled protocols
Public bug reported: We have had problems with openvswitch agent continuously restarting and never actually completing setup because of this: # Completed by iptables_manager ; Stdout: ; Stderr: iptables-restore v1.4.21: multiport only works with TCP, UDP, UDPLITE, SCTP and DCCP Error occurred at line: 83 Try `iptables-restore -h' or 'iptables-restore --help' for more information. 83. -I neutron-openvswi- 69 -s -p 112 -m multiport --dports 1:65535 -j RETURN --- Someone has managed to inject a rule that is, effectively, a DoS. ** 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/1749667 Title: neutron doesn't correctly handle unknown protocols and should whitelist known and handled protocols Status in neutron: New Bug description: We have had problems with openvswitch agent continuously restarting and never actually completing setup because of this: # Completed by iptables_manager ; Stdout: ; Stderr: iptables-restore v1.4.21: multiport only works with TCP, UDP, UDPLITE, SCTP and DCCP Error occurred at line: 83 Try `iptables-restore -h' or 'iptables-restore --help' for more information. 83. -I neutron-openvswi- 69 -s -p 112 -m multiport --dports 1:65535 -j RETURN --- Someone has managed to inject a rule that is, effectively, a DoS. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1749667/+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 1758353] [NEW] neutron - qr- and qg- interfaces looses their vlan tag
Public bug reported: On a running instance, we have had several occasions of network issues. During the last issue we noticed that the interfaces lost their vlan tags in openvswitch: ovs-vsctl show |grep qg-fb5a3595-48 -A 10 Port "qg-fb5a3595-48" Interface "qg-fb5a3595-48" type: internal --- A complete restart of neutron-l3-agent caused a migration and now it works with a different vlan tag: ovs-vsctl show |grep -A 10 qg-fb5a3595-48 Port "qg-fb5a3595-48" tag: 52 Interface "qg-fb5a3595-48" type: internal --- How is this possible? ** 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/1758353 Title: neutron - qr- and qg- interfaces looses their vlan tag Status in neutron: New Bug description: On a running instance, we have had several occasions of network issues. During the last issue we noticed that the interfaces lost their vlan tags in openvswitch: ovs-vsctl show |grep qg-fb5a3595-48 -A 10 Port "qg-fb5a3595-48" Interface "qg-fb5a3595-48" type: internal --- A complete restart of neutron-l3-agent caused a migration and now it works with a different vlan tag: ovs-vsctl show |grep -A 10 qg-fb5a3595-48 Port "qg-fb5a3595-48" tag: 52 Interface "qg-fb5a3595-48" type: internal --- How is this possible? To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1758353/+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 1995714] [NEW] cold migration shouldn't spin up the vm ins a resize step
Public bug reported: disable a compute node run migration on a vm not running, it will still have to start on that compute node to do resize... next imagine that the compute node has gone down, why can't it just do a new scheduling and start running on a existing/not-disabled node? this is with shared storage btw... ** 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/1995714 Title: cold migration shouldn't spin up the vm ins a resize step Status in OpenStack Compute (nova): New Bug description: disable a compute node run migration on a vm not running, it will still have to start on that compute node to do resize... next imagine that the compute node has gone down, why can't it just do a new scheduling and start running on a existing/not-disabled node? this is with shared storage btw... To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1995714/+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 2043486] [NEW] VM stuck in unshelving
Public bug reported: VM:s stuck in unshelving has no way forward. They are stuck in limbo and require database hacks to workaround. There has to be something a admin can try to restart or reset the unshelve process. (running on openstack yoga, installed via kolla-ansible) ** 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/2043486 Title: VM stuck in unshelving Status in OpenStack Compute (nova): New Bug description: VM:s stuck in unshelving has no way forward. They are stuck in limbo and require database hacks to workaround. There has to be something a admin can try to restart or reset the unshelve process. (running on openstack yoga, installed via kolla-ansible) To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/2043486/+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 1308984] [NEW] Floating IP addresses ordered in a weird way
Public bug reported:
The floating ip:s are ordered according to UUID instead of IP, more
information in the patch.
---
commit 83a10bf02a5079513741039860208e277e1d12e4
Author: Ian Kumlien
Date: Thu Apr 17 13:49:32 2014 +0200
Sorting floating IP:s according to IP.
While using alot of manually allocated floating ip:s we wondered why
the IP list wasn't sorted. While looking at it we found that the UI
actually does sort the IP but according to the UUID instead of the
actual IP address.
This change fixes this so that it's sorted according to IP.
Found-By: Marko Bocevski
diff --git
a/openstack_dashboard/dashboards/project/access_and_security/floating_ips/workflows.py
b/openstack_dashboard/dashboards/project/access_and_security/floating_ips/workflows.py
index c4ebbd1..d884dee 100644
---
a/openstack_dashboard/dashboards/project/access_and_security/floating_ips/workflows.py
+++
b/openstack_dashboard/dashboards/project/access_and_security/floating_ips/workflows.py
@@ -69,7 +69,7 @@ class AssociateIPAction(workflows.Action):
exceptions.handle(self.request,
_('Unable to retrieve floating IP addresses.'),
redirect=redirect)
-options = sorted([(ip.id, ip.ip) for ip in ips if not ip.port_id])
+options = sorted([(ip.ip, ip.ip) for ip in ips if not ip.port_id])
if options:
options.insert(0, ("", _("Select an IP address")))
else:
** Affects: horizon
Importance: Undecided
Status: New
** Patch added: "horizion-sort-ips.diff"
https://bugs.launchpad.net/bugs/1308984/+attachment/4086149/+files/horizion-sort-ips.diff
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1308984
Title:
Floating IP addresses ordered in a weird way
Status in OpenStack Dashboard (Horizon):
New
Bug description:
The floating ip:s are ordered according to UUID instead of IP, more
information in the patch.
---
commit 83a10bf02a5079513741039860208e277e1d12e4
Author: Ian Kumlien
Date: Thu Apr 17 13:49:32 2014 +0200
Sorting floating IP:s according to IP.
While using alot of manually allocated floating ip:s we wondered why
the IP list wasn't sorted. While looking at it we found that the UI
actually does sort the IP but according to the UUID instead of the
actual IP address.
This change fixes this so that it's sorted according to IP.
Found-By: Marko Bocevski
diff --git
a/openstack_dashboard/dashboards/project/access_and_security/floating_ips/workflows.py
b/openstack_dashboard/dashboards/project/access_and_security/floating_ips/workflows.py
index c4ebbd1..d884dee 100644
---
a/openstack_dashboard/dashboards/project/access_and_security/floating_ips/workflows.py
+++
b/openstack_dashboard/dashboards/project/access_and_security/floating_ips/workflows.py
@@ -69,7 +69,7 @@ class AssociateIPAction(workflows.Action):
exceptions.handle(self.request,
_('Unable to retrieve floating IP addresses.'),
redirect=redirect)
-options = sorted([(ip.id, ip.ip) for ip in ips if not ip.port_id])
+options = sorted([(ip.ip, ip.ip) for ip in ips if not ip.port_id])
if options:
options.insert(0, ("", _("Select an IP address")))
else:
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1308984/+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
