[Yahoo-eng-team] [Bug 1884708] [NEW] explicity_egress_direction prevents learning of local MACs and causes flooding of ingress packets
Public bug reported:
We took this bug fix: https://bugs.launchpad.net/neutron/+bug/1732067
and then also backported ourselves
https://bugs.launchpad.net/neutron/+bug/1866445
The latter is for iptables based firewall.
We have VLAN based networks, and seeing ingress packets destined to
local MACs being flooded. We are not seeing any local MACs present under
ovs-appctl fdb/show br-int.
Consider following example:
HOST 1:
MAC A = fa:16:3e:c1:01:43
MAC B = fa:16:3e:de:0b:8a
HOST 2:
MAC C = fa:16:3e:d6:3f:31
A is talking to C. Snooping on qvo interface of B, we are seeing all the
traffic destined to MAC A (along with other unicast traffic not destined
to or sourced from MAC B. Neither Mac A or B are present in br-int FDB,
despite sending heavy traffic.
Here is ofproto trace for such packet. in_port 8313 is qvo of MAC A:
sudo ovs-appctl ofproto/trace br-int
in_port=8313,tcp,dl_src=fa:16:3e:c1:01:43,dl_dst=fa:16:3e:d6:3f:31
Flow:
tcp,in_port=8313,vlan_tci=0x,dl_src=fa:16:3e:c1:01:43,dl_dst=fa:16:3e:d6:3f:31,nw_src=0.0.0.0,nw_dst=0.0.0.0,nw_tos=0,nw_ecn=0,nw_ttl=0,tp_src=0,tp_dst=0,tcp_flags=0
bridge("br-int")
0. in_port=8313, priority 9, cookie 0x9a67096130ac45c2
goto_table:25
25. in_port=8313,dl_src=fa:16:3e:c1:01:43, priority 2, cookie 0x9a67096130ac45c2
goto_table:60
60. in_port=8313,dl_src=fa:16:3e:c1:01:43, priority 9, cookie 0x9a67096130ac45c2
resubmit(,61)
61.
in_port=8313,dl_src=fa:16:3e:c1:01:43,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00,
priority 10, cookie 0x9a67096130ac45c2
push_vlan:0x8100
set_field:4098->vlan_vid
output:1
bridge("br-ext")
0. in_port=2, priority 2, cookie 0xab09adf2af892674
goto_table:1
1. priority 0, cookie 0xab09adf2af892674
goto_table:2
2. in_port=2,dl_vlan=2, priority 4, cookie 0xab09adf2af892674
set_field:4240->vlan_vid
NORMAL
-> forwarding to learned port
bridge("br-vlan")
-
0. priority 1, cookie 0x651552fc69601a2d
goto_table:3
3. priority 1, cookie 0x651552fc69601a2d
NORMAL
-> forwarding to learned port
Final flow:
tcp,in_port=8313,dl_vlan=2,dl_vlan_pcp=0,vlan_tci1=0x,dl_src=fa:16:3e:c1:01:43,dl_dst=fa:16:3e:d6:3f:31,nw_src=0.0.0.0,nw_dst=0.0.0.0,nw_tos=0,nw_ecn=0,nw_ttl=0,tp_src=0,tp_dst=0,tcp_flags=0
Megaflow:
recirc_id=0,eth,ip,in_port=8313,vlan_tci=0x/0x1fff,dl_src=fa:16:3e:c1:01:43,dl_dst=fa:16:3e:d6:3f:31,nw_frag=no
Datapath actions: push_vlan(vid=144,pcp=0),51
Because it took output: action from table=61, added by fix
explicitly_egress_direct, the local MAC is not learned. But on ingress, the
packet is hitting table=60's NORMAL action, causing it to be flooded because it
never knows where to send the local MAC.
sudo ovs-appctl ofproto/trace br-int
in_port=1,dl_vlan=144,dl_src=fa:16:3e:d6:3f:31,dl_dst=fa:16:3e:c1:01:43
Flow:
in_port=1,dl_vlan=144,dl_vlan_pcp=0,vlan_tci1=0x,dl_src=fa:16:3e:d6:3f:31,dl_dst=fa:16:3e:c1:01:43,dl_type=0x
bridge("br-int")
0. in_port=1,dl_vlan=144, priority 3, cookie 0x9a67096130ac45c2
set_field:4098->vlan_vid
goto_table:60
60. priority 3, cookie 0x9a67096130ac45c2
NORMAL
-> no learned MAC for destination, flooding
bridge("br-vlan")
-
0. in_port=4, priority 2, cookie 0x651552fc69601a2d
goto_table:1
1. priority 0, cookie 0x651552fc69601a2d
goto_table:2
2. in_port=4, priority 2, cookie 0x651552fc69601a2d
drop
bridge("br-tun")
0. in_port=1, priority 1, cookie 0xf1baf24d000c6f7c
goto_table:1
1. priority 0, cookie 0xf1baf24d000c6f7c
goto_table:2
2. dl_dst=00:00:00:00:00:00/01:00:00:00:00:00, priority 0, cookie
0xf1baf24d000c6f7c
goto_table:20
20. priority 0, cookie 0xf1baf24d000c6f7c
goto_table:22
22. priority 0, cookie 0xf1baf24d000c6f7c
drop
Final flow:
in_port=1,dl_vlan=2,dl_vlan_pcp=0,vlan_tci1=0x,dl_src=fa:16:3e:d6:3f:31,dl_dst=fa:16:3e:c1:01:43,dl_type=0x
Megaflow:
recirc_id=0,eth,in_port=1,dl_vlan=144,dl_vlan_pcp=0,dl_src=fa:16:3e:d6:3f:31,dl_dst=fa:16:3e:c1:01:43,dl_type=0x
Datapath actions:
pop_vlan,push_vlan(vid=2,pcp=0),7,pop_vlan,46,26,57,58,13,6,61,66,68,22,23,72,78,79,34,81,83,2,18,87,33,88,90,91,94,95,99,100,101,102,103,106,108,113,115,116,125,132,133,134,144,145,146,147,165,168,169,170,173,174,175,178,201,203,204,205,216,222,148,150,200,160,181,54,159,151,110,182,114,233,241,212,238,154,11,213,70,29,37,131,45,93,14,139,48,105,152,129,28,12,107,172,196,3,4,62,40,183,124,20,32,67,82,135,153,84,98,109,111,123,5,65,119,120,104,122,128,130,137,142,143,121,141,176,177,179,184,186,190
dump-flows br-int indicates it first hits this rule:
cookie=0x6832197111786c03, duration=107845.507s, table=0,
n_packets=98500552445, n_bytes=66585173373354, idle_age=0,
hard_age=65534, priority=3,in_port=1,dl_vlan=144
actions=mod_vlan_vid:1,resubmit(,60)
then at table=60, the only rule it matches is the final NORMAL
[Yahoo-eng-team] [Bug 1836681] Re: attach volume succeeded but device not found on guest machine
[Expired for OpenStack Compute (nova) because there has been no activity
for 60 days.]
** Changed in: nova
Status: Incomplete => Expired
--
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/1836681
Title:
attach volume succeeded but device not found on guest machine
Status in OpenStack Compute (nova):
Expired
Bug description:
we are using OpenStack Queens:
nova-common/xenial,now 2:17.0.9-6~u16.01+mcp189 all [installed]
nova-compute/xenial,now 2:17.0.9-6~u16.01+mcp189 all [installed,automatic]
nova-compute-kvm/xenial,now 2:17.0.9-6~u16.01+mcp189 all [installed]
guest vm uses windows 2012 datacenter edition
after successfully executing openstack server add volume
${instance_id} ${volume_id}, we observe volume status has changed to
in-used and attachments info are correctly stored in both nova and
neutron. But device does not show up in guest machine.
we execute `virsh dumpxml ${instance_id}` but device is not there. We
then try to edit directly by executing `virsh edit ${instance_id}` and
we see the device with proper attachments info...
At last we have to shutdown the vm and boot again to solve the
problem.
command line outputs are put below,
/var/lib/libvirt/qemu# virsh dumpxml 55 --inactive
.
# virsh domblklist 55
Target Source
vdavms/xxx
vdbvms/
manually attach vdc reports `vdc` in-used
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1836681/+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 1884695] [NEW] allow less strict cpu flag comparison
Public bug reported: Description === Nova uses strict cpu flag comparison during live migration, this introduces some problems when migrating with some cpu flags which do not affect actually migration. For example, `monitoring` flag could be neglected safely. So I think it might be reasonable to ignore some features provided from user input, whether static by configuration or dynamically from api input. ** 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/1884695 Title: allow less strict cpu flag comparison Status in OpenStack Compute (nova): New Bug description: Description === Nova uses strict cpu flag comparison during live migration, this introduces some problems when migrating with some cpu flags which do not affect actually migration. For example, `monitoring` flag could be neglected safely. So I think it might be reasonable to ignore some features provided from user input, whether static by configuration or dynamically from api input. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1884695/+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 1884606] [NEW] cloudinit.net refactor: find_fallback_nic
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884606 Title: cloudinit.net refactor: find_fallback_nic Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884606/+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 1884603] [NEW] cloudinit.net refactor: device_devid
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884603 Title: cloudinit.net refactor: device_devid Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884603/+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 1884617] [NEW] cloudinit.net refactor: is_bridge
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884617 Title: cloudinit.net refactor: is_bridge Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884617/+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 1884613] [NEW] cloudinit.net refactor: get_interfaces_by_mac
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884613 Title: cloudinit.net refactor: get_interfaces_by_mac Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884613/+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 1884604] [NEW] cloudinit.net refactor: device_driver
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884604 Title: cloudinit.net refactor: device_driver Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884604/+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 1884609] [NEW] cloudinit.net refactor: get_ib_hwaddrs_by_interface
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884609 Title: cloudinit.net refactor: get_ib_hwaddrs_by_interface Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884609/+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 1884610] [NEW] cloudinit.net refactor: get_ib_interface_hwaddr
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884610 Title: cloudinit.net refactor: get_ib_interface_hwaddr Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884610/+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 1884616] [NEW] cloudinit.net refactor: is_bond
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884616 Title: cloudinit.net refactor: is_bond Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884616/+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 1884605] [NEW] cloudinit.net refactor: extract_physdevs
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884605 Title: cloudinit.net refactor: extract_physdevs Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884605/+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 1884607] [NEW] cloudinit.net refactor: generate_fallback_config
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884607 Title: cloudinit.net refactor: generate_fallback_config Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884607/+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 1884608] [NEW] cloudinit.net refactor: get_devicelist
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884608 Title: cloudinit.net refactor: get_devicelist Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884608/+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 1884615] [NEW] cloudinit.net refactor: interface_has_own_mac
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884615 Title: cloudinit.net refactor: interface_has_own_mac Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884615/+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 1884611] [NEW] cloudinit.net refactor: get_interface_mac
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884611 Title: cloudinit.net refactor: get_interface_mac Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884611/+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 1884612] [NEW] cloudinit.net refactor: get_interfaces
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884612 Title: cloudinit.net refactor: get_interfaces Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884612/+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 1884614] [NEW] cloudinit.net refactor: get_master
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884614 Title: cloudinit.net refactor: get_master Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884614/+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 1884600] [NEW] cloudinit.net refactor: _get_current_rename_info
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884600 Title: cloudinit.net refactor: _get_current_rename_info Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884600/+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 1884601] [NEW] cloudinit.net refactor: _rename_interfaces
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884601 Title: cloudinit.net refactor: _rename_interfaces Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884601/+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 1884602] [NEW] cloudinit.net refactor: apply_network_config_names
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884602 Title: cloudinit.net refactor: apply_network_config_names Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884602/+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 1884624] [NEW] cloudinit.net refactor: is_wireless
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884624 Title: cloudinit.net refactor: is_wireless Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884624/+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 1884620] [NEW] cloudinit.net refactor: is_present
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884620 Title: cloudinit.net refactor: is_present Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884620/+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 1884623] [NEW] cloudinit.net refactor: is_vlan
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884623 Title: cloudinit.net refactor: is_vlan Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884623/+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 1884618] [NEW] cloudinit.net refactor: is_connected
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884618 Title: cloudinit.net refactor: is_connected Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884618/+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 1884619] [NEW] cloudinit.net refactor: is_physical
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884619 Title: cloudinit.net refactor: is_physical Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884619/+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 1884626] [NEW] cloudinit.net refactor: wait_for_physdevs
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884626 Title: cloudinit.net refactor: wait_for_physdevs Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884626/+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 1884621] [NEW] cloudinit.net refactor: is_renamed
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884621 Title: cloudinit.net refactor: is_renamed Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884621/+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 1884625] [NEW] cloudinit.net refactor: master_is_bridge_or_bond
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884625 Title: cloudinit.net refactor: master_is_bridge_or_bond Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884625/+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 1884622] [NEW] cloudinit.net refactor: is_up
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884622 Title: cloudinit.net refactor: is_up Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884622/+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 1884627] [NEW] cloudinit.net refactor: get_dev_features
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884627 Title: cloudinit.net refactor: get_dev_features Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884627/+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 1884628] [NEW] cloudinit.net refactor: has_netfail_standby_feature
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884628 Title: cloudinit.net refactor: has_netfail_standby_feature Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884628/+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 1884632] [NEW] cloudinit.net refactor: is_netfail_standby
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884632 Title: cloudinit.net refactor: is_netfail_standby Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884632/+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 1884629] [NEW] cloudinit.net refactor: is_netfailover
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884629 Title: cloudinit.net refactor: is_netfailover Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884629/+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 1884630] [NEW] cloudinit.net refactor: is_netfail_master
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884630 Title: cloudinit.net refactor: is_netfail_master Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884630/+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 1884631] [NEW] cloudinit.net refactor: is_netfail_primary
Public bug reported: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Triaged ** Tags: net-refactor ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Tags added: net-refactor -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884631 Title: cloudinit.net refactor: is_netfail_primary Status in cloud-init: Triaged Bug description: This bug is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the function named in the title of this bug. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884631/+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 1884599] [NEW] cloudinit.net refactor: TEST BUG
Public bug reported: This bug report is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the named function. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy ** Affects: cloud-init Importance: Low Status: Invalid ** Changed in: cloud-init Importance: Undecided => Low ** Changed in: cloud-init Status: New => Triaged ** Changed in: cloud-init Status: Triaged => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1884599 Title: cloudinit.net refactor: TEST BUG Status in cloud-init: Invalid Bug description: This bug report is tracking part of the refactor of cloudinit.net into cloudinit.distros.networking, specifically the refactoring of the named function. See [0] for further details. [0] https://cloudinit.readthedocs.io/en/latest/topics/hacking.html #cloudinit-net-cloudinit-distros-networking-hierarchy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1884599/+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 1884596] [NEW] image import copy-to-store will start multiple importing threads due to race condition
Public bug reported: I'm filing this bug a little prematurely because Abhi and I didn't get a chance to fully discuss it. However, looking at the code and the behavior I'm seeing due to another bug (1884587), I feel rather confident. Especially in a situation where glance is running on multiple control plane nodes (i.e. any real-world situation), I believe there is a race condition whereby two closely-timed requests to copy an image to a store will result in two copy operations in glance proceeding in parallel. I believe this to be the case due to a common "test-and-set that isn't atomic" error. In the API layer, glance checks that an import copy-to-store operation isn't already in progress here: https://github.com/openstack/glance/blob/e6db0b10a703037f754007bef6f56451086850cd/glance/api/v2/images.py#L167 And if that passes, it proceeds to setup the task as a thread here: https://github.com/openstack/glance/blob/e6db0b10a703037f754007bef6f56451086850cd/glance/api/v2/images.py#L197 which may start running immediately or sometime in the future. Once running, that code updates a property on the image to indicate that the task is running here: https://github.com/openstack/glance/blob/e6db0b10a703037f754007bef6f56451086850cd/glance/async_/flows/api_image_import.py#L479-L484 Between those two events, if another API user makes the same request, glance will not realize that a thread is already running to complete the initial task and will start another. In a situation where a user spawns a thousand new instances to a thousand compute nodes in a single operation where the image needs copying first, it's highly plausible to have _many_ duplicate glance operations going, impacting write performance on the rbd cluster at the very least. As evidence that this can happen, we see an abnormally extended race window because of the aforementioned bug (1884587) where we fail to update the property that indicates the task is running. In a test we see a large number of them get started, followed by a cascade of failures when they fail to update that image property, implying that many such threads are running. If this situation is allowed to happen when the property does *not* fail to update, I believe we would end up with glance copying the image to the destination in multiple threads simultaneously. That is much harder to simulate in practice in a development environment, but the other bug makes it happen every time since we never update the image property to prevent it and thus the window is long. Abhi also brought up the case where if this race occurs on the same node, the second attempt *may* actually start copying the partial image in the staging directory to the destination, finish early, and then mark the image as "copied to $store" such that nova will attempt to use the partial image immediately, resulting in a corrupted disk and various levels of failure after that. Note that it's not clear if that's really possible or not, but I'm putting it here so the glance gurus can validate. The use of the os_glance_importing_to_stores property to "lock" a copy to a particular store is good, except that updating that list atomically means that the above mentioned race will not have anything to check after the update to see if it was the race loser. I don't see any checks in the persistence layer to ensure that an UPDATE to the row with this property doesn't already have a given store in it, or do any kind of merge. This also leads me to worry that two parallel requests to copy an image to two different stores may result in clobbering the list of stores-in-progress and potentially also the final list of stores at rest. This is just conjecture at this point, I just haven't seen anywhere that situation is accounted for. ** 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/1884596 Title: image import copy-to-store will start multiple importing threads due to race condition Status in Glance: New Bug description: I'm filing this bug a little prematurely because Abhi and I didn't get a chance to fully discuss it. However, looking at the code and the behavior I'm seeing due to another bug (1884587), I feel rather confident. Especially in a situation where glance is running on multiple control plane nodes (i.e. any real-world situation), I believe there is a race condition whereby two closely-timed requests to copy an image to a store will result in two copy operations in glance proceeding in parallel. I believe this to be the case due to a common "test-and-set that isn't atomic" error. In the API layer, glance checks that an import copy-to-store operation isn't already in progress here: https://github.com/openstack/glance/blob/e6db0b10a703037f754007bef6f56451086850cd/glance/api/v2/images.py#L167 And if that passes,
[Yahoo-eng-team] [Bug 1884587] [NEW] image import copy-to-store API should reflect proper authorization
Public bug reported: In testing the image import copy-to-store mechanism from Nova, I hit an issue that seems clearly to be a bug. Scenario: A user boots an instance from an image they have permission to see. Nova uses their credentials to start an image import copy-to-store operation, which succeeds: "POST /v2/images/e6b1a7d0-ccd8-4be3-bef7-69c68fca4313/import HTTP/1.1" 202 211 0.481190 Task [888e97e5-496d-4b94-b530-218d633f866a] status changing from pending to processing Note the 202 return code. My code polls for a $timeout period, waiting for the image to either arrive at the new store, or be marked as error, which never happens ($timeout=600s). The glance log shows (trace truncated): glance-api[14039]: File "/opt/stack/glance/glance/async_/flows/api_image_import.py", line 481, in get_flow glance-api[14039]: stores if glance-api[14039]: File "/opt/stack/glance/glance/api/authorization.py", line 296, in forbidden_key glance-api[14039]: raise exception.Forbidden(message % key) glance-api[14039]: glance.common.exception.Forbidden: You are not permitted to modify 'os_glance_importing_to_stores' on this image. So apparently Nova is unable to use the user's credentials to initiate a copy-to-store operation. That surprises me and I think it likely isn't the access control we should be enforcing. However, if we're going to reject the operation, we should reject it at the time the HTTP response is sent, not later async, since we can check authorization right then and there. The problem in this case is that from the outside, I have no way of knowing that the task fails subsequently. I receive a 202, which means I should start polling for completion. The task fails to load/run and thus can't update any status on the image, and I'm left to wait for 600s before I give up. So, at the very least, we're not checking the same set of permissions during the HTTP POST call, and we should be. I also would tend to argue that the user should be allowed to copy the image and not require an admin to do it, perhaps with some additional policy element to control that. However, I have to be able to determine when and when not to wait for 600s. ** 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/1884587 Title: image import copy-to-store API should reflect proper authorization Status in Glance: New Bug description: In testing the image import copy-to-store mechanism from Nova, I hit an issue that seems clearly to be a bug. Scenario: A user boots an instance from an image they have permission to see. Nova uses their credentials to start an image import copy-to-store operation, which succeeds: "POST /v2/images/e6b1a7d0-ccd8-4be3-bef7-69c68fca4313/import HTTP/1.1" 202 211 0.481190 Task [888e97e5-496d-4b94-b530-218d633f866a] status changing from pending to processing Note the 202 return code. My code polls for a $timeout period, waiting for the image to either arrive at the new store, or be marked as error, which never happens ($timeout=600s). The glance log shows (trace truncated): glance-api[14039]: File "/opt/stack/glance/glance/async_/flows/api_image_import.py", line 481, in get_flow glance-api[14039]: stores if glance-api[14039]: File "/opt/stack/glance/glance/api/authorization.py", line 296, in forbidden_key glance-api[14039]: raise exception.Forbidden(message % key) glance-api[14039]: glance.common.exception.Forbidden: You are not permitted to modify 'os_glance_importing_to_stores' on this image. So apparently Nova is unable to use the user's credentials to initiate a copy-to-store operation. That surprises me and I think it likely isn't the access control we should be enforcing. However, if we're going to reject the operation, we should reject it at the time the HTTP response is sent, not later async, since we can check authorization right then and there. The problem in this case is that from the outside, I have no way of knowing that the task fails subsequently. I receive a 202, which means I should start polling for completion. The task fails to load/run and thus can't update any status on the image, and I'm left to wait for 600s before I give up. So, at the very least, we're not checking the same set of permissions during the HTTP POST call, and we should be. I also would tend to argue that the user should be allowed to copy the image and not require an admin to do it, perhaps with some additional policy element to control that. However, I have to be able to determine when and when not to wait for 600s. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1884587/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe :
[Yahoo-eng-team] [Bug 1884571] [NEW] Horizon Attach interface exception, if subnet contains letters with ACUTE
Public bug reported: Hy! We run into a small "problem". (Using Rocky) A subnet in a project was named with a letter "é" and the horizon dropped an exception, when we tried to attach a new interface to the instance. When spin up a new instance, and add it to this network, it's just works fine. After the subnet was renamed, the Attach interface started working again. Not a big deal, but maybe someone can reproduce, and it can be fixed. Thanks, Peter The error message: [Mon Jun 22 17:51:28.619521 2020] [wsgi:error] [pid 1629918:tid 140338093852416] [remote 192.168.51.253:47116] Internal Server Error: /project/instances/b88b44f1-2b3d-4539-b21c-b45029f959a1/attach_interface [Mon Jun 22 17:51:28.619638 2020] [wsgi:error] [pid 1629918:tid 140338093852416] [remote 192.168.51.253:47116] Traceback (most recent call last): [Mon Jun 22 17:51:28.619665 2020] [wsgi:error] [pid 1629918:tid 140338093852416] [remote 192.168.51.253:47116] File "/usr/lib/python2.7/dist-packages/django/core/handlers/exception.py", line 41, in inner [Mon Jun 22 17:51:28.619685 2020] [wsgi:error] [pid 1629918:tid 140338093852416] [remote 192.168.51.253:47116] response = get_response(request) [Mon Jun 22 17:51:28.619706 2020] [wsgi:error] [pid 1629918:tid 140338093852416] [remote 192.168.51.253:47116] File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line 187, in _get_response [Mon Jun 22 17:51:28.619724 2020] [wsgi:error] [pid 1629918:tid 140338093852416] [remote 192.168.51.253:47116] response = self.process_exception_by_middleware(e, request) [Mon Jun 22 17:51:28.619743 2020] [wsgi:error] [pid 1629918:tid 140338093852416] [remote 192.168.51.253:47116] File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line 185, in _get_response [Mon Jun 22 17:51:28.619761 2020] [wsgi:error] [pid 1629918:tid 140338093852416] [remote 192.168.51.253:47116] response = wrapped_callback(request, *callback_args, **callback_kwargs) [Mon Jun 22 17:51:28.619780 2020] [wsgi:error] [pid 1629918:tid 140338093852416] [remote 192.168.51.253:47116] File "/usr/lib/python2.7/dist-packages/horizon/decorators.py", line 36, in dec [Mon Jun 22 17:51:28.619798 2020] [wsgi:error] [pid 1629918:tid 140338093852416] [remote 192.168.51.253:47116] return view_func(request, *args, **kwargs) [Mon Jun 22 17:51:28.619816 2020] [wsgi:error] [pid 1629918:tid 140338093852416] [remote 192.168.51.253:47116] File "/usr/lib/python2.7/dist-packages/horizon/decorators.py", line 52, in dec [Mon Jun 22 17:51:28.619834 2020] [wsgi:error] [pid 1629918:tid 140338093852416] [remote 192.168.51.253:47116] return view_func(request, *args, **kwargs) [Mon Jun 22 17:51:28.619853 2020] [wsgi:error] [pid 1629918:tid 140338093852416] [remote 192.168.51.253:47116] File "/usr/lib/python2.7/dist-packages/horizon/decorators.py", line 36, in dec [Mon Jun 22 17:51:28.619871 2020] [wsgi:error] [pid 1629918:tid 140338093852416] [remote 192.168.51.253:47116] return view_func(request, *args, **kwargs) [Mon Jun 22 17:51:28.619931 2020] [wsgi:error] [pid 1629918:tid 140338093852416] [remote 192.168.51.253:47116] File "/usr/lib/python2.7/dist-packages/horizon/decorators.py", line 113, in dec [Mon Jun 22 17:51:28.619955 2020] [wsgi:error] [pid 1629918:tid 140338093852416] [remote 192.168.51.253:47116] return view_func(request, *args, **kwargs) [Mon Jun 22 17:51:28.619973 2020] [wsgi:error] [pid 1629918:tid 140338093852416] [remote 192.168.51.253:47116] File "/usr/lib/python2.7/dist-packages/horizon/decorators.py", line 84, in dec [Mon Jun 22 17:51:28.619992 2020] [wsgi:error] [pid 1629918:tid 140338093852416] [remote 192.168.51.253:47116] return view_func(request, *args, **kwargs) [Mon Jun 22 17:51:28.620010 2020] [wsgi:error] [pid 1629918:tid 140338093852416] [remote 192.168.51.253:47116] File "/usr/lib/python2.7/dist-packages/django/views/generic/base.py", line 68, in view [Mon Jun 22 17:51:28.620029 2020] [wsgi:error] [pid 1629918:tid 140338093852416] [remote 192.168.51.253:47116] return self.dispatch(request, *args, **kwargs) [Mon Jun 22 17:51:28.620061 2020] [wsgi:error] [pid 1629918:tid 140338093852416] [remote 192.168.51.253:47116] File "/usr/lib/python2.7/dist-packages/django/views/generic/base.py", line 88, in dispatch [Mon Jun 22 17:51:28.620081 2020] [wsgi:error] [pid 1629918:tid 140338093852416] [remote 192.168.51.253:47116] return handler(request, *args, **kwargs) [Mon Jun 22 17:51:28.620123 2020] [wsgi:error] [pid 1629918:tid 140338093852416] [remote 192.168.51.253:47116] File "/usr/lib/python2.7/dist-packages/django/views/generic/edit.py", line 174, in get [Mon Jun 22 17:51:28.620152 2020] [wsgi:error] [pid 1629918:tid 140338093852416] [remote 192.168.51.253:47116] return self.render_to_response(self.get_context_data()) [Mon Jun 22 17:51:28.620176 2020] [wsgi:error] [pid 1629918:tid 140338093852416] [remote 192.168.51.253:47116] File
[Yahoo-eng-team] [Bug 1884532] [NEW] inconsistent data in ipamallocations
Public bug reported: Sometimes I saw database is not consistent for some reasons, for example, as shown below MariaDB [neutron]> select * from ipamsubnets where neutron_subnet_id='9a8fd2b0-743c-4500-8978-9e5bf9b38347' -> ; +--+--+ | id | neutron_subnet_id| +--+--+ | 85e7171c-2648-4447-ada6-a37c3c113686 | 9a8fd2b0-743c-4500-8978-9e5bf9b38347 | +--+--+ 1 row in set (0.00 sec) MariaDB [neutron]> select * from ipamallocations where ipam_subnet_id = '85e7171c-2648-4447-ada6-a37c3c113686' \G *** 1. row *** ip_address: 10.13.45.1 status: ALLOCATED ipam_subnet_id: 85e7171c-2648-4447-ada6-a37c3c113686 *** 2. row *** ip_address: 10.13.45.2 status: ALLOCATED ipam_subnet_id: 85e7171c-2648-4447-ada6-a37c3c113686 *** 3. row *** ip_address: 10.13.45.3 status: ALLOCATED ipam_subnet_id: 85e7171c-2648-4447-ada6-a37c3c113686 *** 4. row *** ip_address: 10.13.45.4 status: ALLOCATED ipam_subnet_id: 85e7171c-2648-4447-ada6-a37c3c113686 *** 5. row *** ip_address: 10.13.45.5 status: ALLOCATED ipam_subnet_id: 85e7171c-2648-4447-ada6-a37c3c113686 *** 6. row *** ip_address: 10.13.45.6 status: ALLOCATED ipam_subnet_id: 85e7171c-2648-4447-ada6-a37c3c113686 6 rows in set (0.00 sec) MariaDB [neutron]> select * from ipamallocations where ipam_subnet_id = '85e7171c-2648-4447-ada6-a37c3c113686' \G MariaDB [neutron]> select * from ipallocations where subnet_id='9a8fd2b0-743c-4500-8978-9e5bf9b38347' -> ; +--++--+--+ | port_id | ip_address | subnet_id | network_id | +--++--+--+ | 0ae2630a-76d9-47b1-bf2f-012c2356df75 | 10.13.45.1 | 9a8fd2b0-743c-4500-8978-9e5bf9b38347 | c3ea28cd-e76a-4e49-b538-cc05c0173b83 | | 83b4683a-fb57-4844-9e1d-55b111fa0e19 | 10.13.45.2 | 9a8fd2b0-743c-4500-8978-9e5bf9b38347 | c3ea28cd-e76a-4e49-b538-cc05c0173b83 | | 7f0224dd-c49b-42a8-8c8a-bd3aa6c24223 | 10.13.45.3 | 9a8fd2b0-743c-4500-8978-9e5bf9b38347 | c3ea28cd-e76a-4e49-b538-cc05c0173b83 | | f53b335e-535b-42ce-be53-0d6cee48cf28 | 10.13.45.4 | 9a8fd2b0-743c-4500-8978-9e5bf9b38347 | c3ea28cd-e76a-4e49-b538-cc05c0173b83 | +--++--+--+ 4 rows in set (0.00 sec) MariaDB [neutron]> apparently ipam is not consitent with real ip allocations, when this happens some IP address is not allocatible although openstack port list cannot find it. We are using mariadb for production, and I haven't seen problem like this using MySQL. ** 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/1884532 Title: inconsistent data in ipamallocations Status in neutron: New Bug description: Sometimes I saw database is not consistent for some reasons, for example, as shown below MariaDB [neutron]> select * from ipamsubnets where neutron_subnet_id='9a8fd2b0-743c-4500-8978-9e5bf9b38347' -> ; +--+--+ | id | neutron_subnet_id | +--+--+ | 85e7171c-2648-4447-ada6-a37c3c113686 | 9a8fd2b0-743c-4500-8978-9e5bf9b38347 | +--+--+ 1 row in set (0.00 sec) MariaDB [neutron]> select * from ipamallocations where ipam_subnet_id = '85e7171c-2648-4447-ada6-a37c3c113686' \G *** 1. row *** ip_address: 10.13.45.1 status: ALLOCATED ipam_subnet_id: 85e7171c-2648-4447-ada6-a37c3c113686 *** 2. row *** ip_address: 10.13.45.2 status: ALLOCATED ipam_subnet_id: 85e7171c-2648-4447-ada6-a37c3c113686 *** 3. row *** ip_address: 10.13.45.3 status: ALLOCATED
[Yahoo-eng-team] [Bug 1884527] [NEW] Related dvr routers aren't created on compute nodes
Public bug reported: We observed in our d/s CI that scenario test test_connectivity_through_2_routers is failing for us in topology with 3 controllers and 2 compute nodes. The reason why it was failing is that related routers wasn't created on compute nodes properly. Only routers to which VMs on host were connected were created. After investigation I found out that this regression was caused by patch https://github.com/openstack/neutron/commit/48ea7da6c52ee14f0e9cc244fbc834283a8e74a7 because in some cases when "related router" is updated on L3 agent, it calls get_routers() in https://github.com/openstack/neutron/blob/390c4ac55f3ea883882412afdc1b921c4c3614e1/neutron/agent/l3/agent.py#L702 and that method on server side is looking if requested router is scheduled to the L3 agent or not and is also looking for routers related to the routers on the host. But isn't looking for routers related to the requested one as it is already "related" router. So when L3 agent is already processing related router and will ask server about details of this router, it will not get it as this router isn't scheduled to that compute node (it's only related to other dvr router scheduled to the host). ** Affects: neutron Importance: Medium Assignee: Slawek Kaplonski (slaweq) Status: Confirmed ** Tags: l3-dvr-backlog -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1884527 Title: Related dvr routers aren't created on compute nodes Status in neutron: Confirmed Bug description: We observed in our d/s CI that scenario test test_connectivity_through_2_routers is failing for us in topology with 3 controllers and 2 compute nodes. The reason why it was failing is that related routers wasn't created on compute nodes properly. Only routers to which VMs on host were connected were created. After investigation I found out that this regression was caused by patch https://github.com/openstack/neutron/commit/48ea7da6c52ee14f0e9cc244fbc834283a8e74a7 because in some cases when "related router" is updated on L3 agent, it calls get_routers() in https://github.com/openstack/neutron/blob/390c4ac55f3ea883882412afdc1b921c4c3614e1/neutron/agent/l3/agent.py#L702 and that method on server side is looking if requested router is scheduled to the L3 agent or not and is also looking for routers related to the routers on the host. But isn't looking for routers related to the requested one as it is already "related" router. So when L3 agent is already processing related router and will ask server about details of this router, it will not get it as this router isn't scheduled to that compute node (it's only related to other dvr router scheduled to the host). To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1884527/+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 1884512] [NEW] [QoS] Race condition during port qos rules deletion
Public bug reported: Deployment using OVS as network backend. QoS enabled. During the port deletion, the QoS OVS agent extension removes the possible QoS rules applied on a port (max BW egress/ingress, min BW egress/ingress). During this process, in "delete_ingress_bw_limit_for_port", the port is checked and then, if exists, it is modified to delete the QoS reference (clear "qos" column in "port" DB register). As seen in [1], the port can be deleted between both operations (retrieval, modification), resulting in an error. [1]http://paste.openstack.org/show/795047/ ** Affects: neutron Importance: Undecided Assignee: Rodolfo Alonso (rodolfo-alonso-hernandez) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1884512 Title: [QoS] Race condition during port qos rules deletion Status in neutron: In Progress Bug description: Deployment using OVS as network backend. QoS enabled. During the port deletion, the QoS OVS agent extension removes the possible QoS rules applied on a port (max BW egress/ingress, min BW egress/ingress). During this process, in "delete_ingress_bw_limit_for_port", the port is checked and then, if exists, it is modified to delete the QoS reference (clear "qos" column in "port" DB register). As seen in [1], the port can be deleted between both operations (retrieval, modification), resulting in an error. [1]http://paste.openstack.org/show/795047/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1884512/+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 1884504] [NEW] nova assume ports with vnic_type=direct-physical use the libvirt interface element when processing network-vif-deleted events
Public bug reported: High level description It should not be able to remove a port that it is attached to a VM. It is allowed to removed a port with with vnic_type=direct-physical. Exception raised: LibvirtConfigGuestHostdevPCI accessing a non existing attribute: mac_addr 2020-02-18 17:41:20.190 8 ERROR oslo_messaging.rpc.server [req-55778a4d-bf76-43cf-8198-02111be843d3 a82e4764680d4805b04dbc843df5ad73 233cc3938ae44e6e9fb21eaaff091999 - default default] Exception during message handling: AttributeError: 'LibvirtConfigGuestHostdevPCI' object has no attribute 'mac_addr' 2020-02-18 17:41:20.190 8 ERROR oslo_messaging.rpc.server Traceback (most recent call last): 2020-02-18 17:41:20.190 8 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/server.py", line 166, in _process_incoming 2020-02-18 17:41:20.190 8 ERROR oslo_messaging.rpc.server res = self.dispatcher.dispatch(message) 2020-02-18 17:41:20.190 8 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 220, in dispatch 2020-02-18 17:41:20.190 8 ERROR oslo_messaging.rpc.server return self._do_dispatch(endpoint, method, ctxt, args) 2020-02-18 17:41:20.190 8 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 190, in _do_dispatch 2020-02-18 17:41:20.190 8 ERROR oslo_messaging.rpc.server result = func(ctxt, **new_args) 2020-02-18 17:41:20.190 8 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/nova/exception_wrapper.py", line 76, in wrapped 2020-02-18 17:41:20.190 8 ERROR oslo_messaging.rpc.server function_name, call_dict, binary) 2020-02-18 17:41:20.190 8 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__ 2020-02-18 17:41:20.190 8 ERROR oslo_messaging.rpc.server self.force_reraise() 2020-02-18 17:41:20.190 8 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in force_reraise 2020-02-18 17:41:20.190 8 ERROR oslo_messaging.rpc.server six.reraise(self.type_, self.value, self.tb) 2020-02-18 17:41:20.190 8 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/nova/exception_wrapper.py", line 67, in wrapped 2020-02-18 17:41:20.190 8 ERROR oslo_messaging.rpc.server return f(self, context, *args, **kw) 2020-02-18 17:41:20.190 8 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 8104, in external_instance_event 2020-02-18 17:41:20.190 8 ERROR oslo_messaging.rpc.server event.tag) 2020-02-18 17:41:20.190 8 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 8014, in _process_instance_vif_deleted_event 2020-02-18 17:41:20.190 8 ERROR oslo_messaging.rpc.server self.driver.detach_interface(context, instance, vif) 2020-02-18 17:41:20.190 8 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 1807, in detach_interface 2020-02-18 17:41:20.190 8 ERROR oslo_messaging.rpc.server interface = guest.get_interface_by_cfg(cfg) 2020-02-18 17:41:20.190 8 ERROR oslo_messaging.rpc.server File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/guest.py", line 246, in get_interface_by_cfg 2020-02-18 17:41:20.190 8 ERROR oslo_messaging.rpc.server if (interface.mac_addr == cfg.mac_addr and 2020-02-18 17:41:20.190 8 ERROR oslo_messaging.rpc.server AttributeError: 'LibvirtConfigGuestHostdevPCI' object has no attribute 'mac_addr' 2020-02-18 17:41:20.190 8 ERROR oslo_messaging.rpc.server Step-by-step reproduction steps 1. Create a vm with a "physical direct" port and attach to a VM (venv) (overcloud) [stack@undercloud-0 ~]$ openstack port list | grep "50.0" | eeb2cc67-046c-4414-a8ea-2be93bdbc542 | tempest-port-smoke-1184295488 | f8:f2:1e:03:9b:e6 | ip_address='50.0.0.110', subnet_id='a9d92b9b-e6e4-40fe-a358-e21921fdbd2d' | ACTIVE | (venv) (overcloud) [stack@undercloud-0 ~]$ openstack port show eeb2cc67-046c-4414-a8ea-2be93bdbc542 +---+--+ | Field | Value | +---+--+ | admin_state_up| UP | | allowed_address_pairs | | | binding_host_id | compute-1.localdomain | | binding_profile | pci_slot=':05:00.3', pci_vendor_info='8086:1572', physical_network='sriov-2' | |
[Yahoo-eng-team] [Bug 1884486] [NEW] subnet create with wrong project
Public bug reported: If we choose create subnet when creating network in dashboard, the default project of subnet will use current project instead of the project setting in creating network. It will cause the difference project between network and subnet, and VM create failed. ** Affects: horizon Importance: Undecided Status: New -- 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/1884486 Title: subnet create with wrong project Status in OpenStack Dashboard (Horizon): New Bug description: If we choose create subnet when creating network in dashboard, the default project of subnet will use current project instead of the project setting in creating network. It will cause the difference project between network and subnet, and VM create failed. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1884486/+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
