[Yahoo-eng-team] [Bug 2040172] [NEW] [OVN] OvnSbSynchronizer - clean/delete segmenthostmappings for unrelated hosts
Public bug reported: neutron.plugins.ml2.drivers.ovn.mech_driver.ovsdb.ovn_db_sync.OvnSbSynchronizer When the `sync_hostname_and_physical_networks` method run's it will compare host physical_networks to mappings in neutrons `segmenthostmappings` table. Any mappings in neutron that is not seen on OVN chassis is then treated as "stale" and cleaned up. This is problematic when there are other plug-ins/agents involved, for example ML2 networking-baremetal[2]. Any segment-host mapping created for baremetal nodes are deleted from the database. And since there is de-duplication[1] on updates from agents - the segment-host mappings are not re-created unless services are re-started or the baremetal node is deleted and re-created in the ironic service. The OvnSbSynchronizer should not remove mappings unless they belong to OVN hosts. [1] https://opendev.org/openstack/neutron/commit/176503e610aee16cb5799a77466579bc55129450 [2] https://opendev.org/openstack/networking-baremetal/src/branch/master/networking_baremetal/agent/ironic_neutron_agent.py ** Affects: neutron Importance: Undecided 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/2040172 Title: [OVN] OvnSbSynchronizer - clean/delete segmenthostmappings for unrelated hosts Status in neutron: In Progress Bug description: neutron.plugins.ml2.drivers.ovn.mech_driver.ovsdb.ovn_db_sync.OvnSbSynchronizer When the `sync_hostname_and_physical_networks` method run's it will compare host physical_networks to mappings in neutrons `segmenthostmappings` table. Any mappings in neutron that is not seen on OVN chassis is then treated as "stale" and cleaned up. This is problematic when there are other plug-ins/agents involved, for example ML2 networking-baremetal[2]. Any segment-host mapping created for baremetal nodes are deleted from the database. And since there is de-duplication[1] on updates from agents - the segment-host mappings are not re-created unless services are re-started or the baremetal node is deleted and re-created in the ironic service. The OvnSbSynchronizer should not remove mappings unless they belong to OVN hosts. [1] https://opendev.org/openstack/neutron/commit/176503e610aee16cb5799a77466579bc55129450 [2] https://opendev.org/openstack/networking-baremetal/src/branch/master/networking_baremetal/agent/ironic_neutron_agent.py To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2040172/+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 2034684] [NEW] UEFI (edk2/ovmf) network boot with OVN fail because no DHCP release reply
Public bug reported: When attempting to verify neutron change[1], we discovered that despite options in DHCPv6 ADV and REQ/REPLY are correct network booting still fails. When comparing traffic capture between openvswitch+neutron-dhcp-agent setup to the ovn setup a significant difference is that: * neutron-dhcp-ageent(dnsmasq) does REPLY to RELEASE with a packet including a dhcpv6 option type Status code (13) success to confirm the release. edk2/ovmf does TFTP transfer of the NBP immediately after recieving this reply. * OVN does not respond with a REPLY to the clients RELEASE. In traffic capture we can see the client repeates the RELEASE several times, but finally give up and raise an error: >>Start PXE over IPv6.. Station IP address is FC01:0:0:0:0:0:0:206 Server IP address is FC00:0:0:0:0:0:0:1 NBP filename is snponly.efi NBP filesize is 0 Bytes PXE-E53: No boot filename received. -- FAILING - sequence on OVN -- No. TimeSource Destination ProtocolLength Info 1 0.00fe80::f816:3eff:fe6f:a0ab :: ICMPv6 118 Router Advertisement from fa:16:3e:6f:a0:ab 2 51.931422 fe80::5054:ff:feb1:a5b0 ff02::1:2 DHCPv6 177 Solicit XID: 0x4f04ed CID: 000430a25dc55972534aa516ff9c9f7c7ac4 3 51.931840 fe80::f816:3eff:feeb:b176 fe80::5054:ff:feb1:a5b0 DHCPv6 198 Advertise XID: 0x4f04ed CID: 000430a25dc55972534aa516ff9c9f7c7ac4 IAA: fc01::2ad 4 56.900421 fe80::5054:ff:feb1:a5b0 ff02::1:2 DHCPv6 219 Request XID: 0x5004ed CID: 000430a25dc55972534aa516ff9c9f7c7ac4 IAA: fc01::2ad 5 56.900726 fe80::f816:3eff:feeb:b176 fe80::5054:ff:feb1:a5b0 DHCPv6 198 Reply XID: 0x5004ed CID: 000430a25dc55972534aa516ff9c9f7c7ac4 IAA: fc01::2ad 6 68.861979 fe80::5054:ff:feb1:a5b0 ff02::1:2 DHCPv6 152 Release XID: 0x5104ed CID: 000430a25dc55972534aa516ff9c9f7c7ac4 IAA: fc01::2ad 7 69.900715 fe80::5054:ff:feb1:a5b0 ff02::1:2 DHCPv6 152 Release XID: 0x5104ed CID: 000430a25dc55972534aa516ff9c9f7c7ac4 IAA: fc01::2ad 8 72.900784 fe80::5054:ff:feb1:a5b0 ff02::1:2 DHCPv6 152 Release XID: 0x5104ed CID: 000430a25dc55972534aa516ff9c9f7c7ac4 IAA: fc01::2ad 9 77.900774 fe80::5054:ff:feb1:a5b0 ff02::1:2 DHCPv6 152 Release XID: 0x5104ed CID: 000430a25dc55972534aa516ff9c9f7c7ac4 IAA: fc01::2ad 10 86.900759 fe80::5054:ff:feb1:a5b0 ff02::1:2 DHCPv6 152 Release XID: 0x5104ed CID: 000430a25dc55972534aa516ff9c9f7c7ac4 IAA: fc01::2ad 11 103.900786 fe80::5054:ff:feb1:a5b0 ff02::1:2 DHCPv6 152 Release XID: 0x5104ed CID: 000430a25dc55972534aa516ff9c9f7c7ac4 IAA: fc01::2ad -- WORKING - sequence on neutron-dhcp-agent (dnsmasq) -- No. TimeSource Destination ProtocolLength Info 1 0.00fe80::f816:3eff:fe38:eef0 ff02::1 ICMPv6 142 Router Advertisement from fa:16:3e:38:ee:f0 2 0.001102fe80::5054:ff:fed9:3d5c ff02::1:2 DHCPv6 116 Solicit XID: 0x71d892 CID: 0004c9b0caa37bce994e85633d7572708047 3 0.001245fe80::f816:3eff:fef5:ef7a fe80::5054:ff:fed9:3d5c DHCPv6 208 Advertise XID: 0x71d892 CID: 0004c9b0caa37bce994e85633d7572708047 IAA: fc01::87 4 0.002436fe80::5054:ff:fed9:3d5c ff02::1:2 DHCPv6 162 Request XID: 0x72d892 CID: 0004c9b0caa37bce994e85633d7572708047 IAA: fc01::87 5 0.002508fe80::f816:3eff:fef5:ef7a fe80::5054:ff:fed9:3d5c DHCPv6 219 Reply XID: 0x72d892 CID: 0004c9b0caa37bce994e85633d7572708047 IAA: fc01::87 6 3.130605fe80::5054:ff:fed9:3d5c ff02::1:2 DHCPv6 223 Request XID: 0x73d892 CID: 0004c9b0caa37bce994e85633d7572708047 IAA: fc01::87 7 3.130791fe80::f816:3eff:fef5:ef7a fe80::5054:ff:fed9:3d5c DHCPv6 256 Reply XID: 0x73d892 CID: 0004c9b0caa37bce994e85633d7572708047 IAA: fc01::2a0 8 3.132060fe80::5054:ff:fed9:3d5c ff02::1:2 DHCPv6 156 Release XID: 0x74d892 CID: 0004c9b0caa37bce994e85633d7572708047 IAA: fc01::87 9 3.132126fe80::f816:3eff:fef5:ef7a fe80::5054:ff:fed9:3d5c DHCPv6 128 Reply XID: 0x74d892 CID: 0004c9b0caa37bce994e85633d7572708047 10 5.477847fc01::2a0 fc00::1 TFTP116 Read Request, File: snponly.efi, Transfer type: octet, tsize=0, blksize=1228, windowsize=4 -- Conclusion is that OVN DHCPv6 implementation need to be fixed, it should reply when the client send a dhcpv6 release. Attached file contain traffic capture files from both the working (dnsmasq dhcp) set-up and the failing (OVN dhcp) set-up. [1] https://re
[Yahoo-eng-team] [Bug 1975542] [NEW] Open vSwitch agent - does not report to the segment plugin
Public bug reported: The atteched devstack configuration `local.conf` can be used to reproduce this issue. In networking-baremetal CI we are seeing an issue where the DHCP agent does not create a namespace for subnets on a routed provider network. No DHCP namespace is created because this test[1] `if (any(s for s in network.subnets if s.enable_dhcp)` returns false. The OVS agent does have the correct configuration, with mappings to the physical_network "mynetwork" on bridge "brbm". $ openstack network agent show ef7ca33a-de9c-4a2b-9af5-e1c9cb029a25 -f yaml admin_state_up: true agent_type: Open vSwitch agent alive: true availability_zone: null binary: neutron-openvswitch-agent configuration: arp_responder_enabled: false baremetal_smartnic: false bridge_mappings: mynetwork: brbm public: br-ex But looking in the database, there are only `segment host mappings` for baremetal nodes. mysql> select * from segmenthostmappings; +--+--+ | segment_id | host | +--+--+ | 712e8a82-a5f9-4506-9520-fc5b4b01529e | 30e70889-d50c-42a8-8776-f5e8cdce3609 | | 712e8a82-a5f9-4506-9520-fc5b4b01529e | a3930bb2-a742-44f8-954e-49be373477db | | 712e8a82-a5f9-4506-9520-fc5b4b01529e | cbb3f623-f300-4dd3-ab09-c05b1e9b9a75 | | ede8201d-0766-4a18-9df0-1b6292f99592 | 30e70889-d50c-42a8-8776-f5e8cdce3609 | | ede8201d-0766-4a18-9df0-1b6292f99592 | a3930bb2-a742-44f8-954e-49be373477db | | ede8201d-0766-4a18-9df0-1b6292f99592 | cbb3f623-f300-4dd3-ab09-c05b1e9b9a75 | +--+--+ 6 rows in set (0.00 sec) If I manually stop the OVS agent service, manually delete the agent and then restart the OVS agent the agent is re-created and mappings are created. stack@devstack:~/devstack$ sudo systemctl stop devstack@q-agt.service stack@devstack:~/devstack$ openstack network agent delete 3921f433-b2f1-4c8f-90d2-deaad6bb5814 stack@devstack:~/devstack$ sudo systemctl start devstack@q-agt.service mysql> select * from segmenthostmappings; +--+--+ | segment_id | host
[Yahoo-eng-team] [Bug 1967742] [NEW] ML2 - Network Context, not possible to see original/current segments
Public bug reported:
When ML2 driver receive NetworkContext after adding network segment
with:
openstack network segment create \
--network e686a356-58d7-4cf0-bdf9-e720d9925ac0 \
--physical-network net3 \
--network-type vlan \
--segment 300 provision-net3
In `update_network_postcommit`, context.current and context.original
both include all segments:
context.current:
{'id': 'e686a356-58d7-4cf0-bdf9-e720d9925ac0',
'name': 'routed_provider_net',
'segments': [
{'provider:network_type': 'vlan',
'provider:physical_network': 'net1',
'provider:segmentation_id': 100},
{'provider:network_type': 'vlan',
'provider:physical_network': 'net2',
'provider:segmentation_id': 200},
{'provider:network_type': 'vlan',
'provider:physical_network': 'net3',
'provider:segmentation_id': 300}]}
context.original:
{'id': 'e686a356-58d7-4cf0-bdf9-e720d9925ac0',
'name': 'routed_provider_net',
'segments': [
{'provider:network_type': 'vlan',
'provider:physical_network': 'net1',
'provider:segmentation_id': 100},
{'provider:network_type': 'vlan',
'provider:physical_network': 'net2',
'provider:segmentation_id': 200},
{'provider:network_type': 'vlan',
'provider:physical_network': 'net3',
'provi der:segmentation_id': 300}]}
Expected results:
context.orignial should not include the new segment on physical_network:
'net3'.
Since both current and original include all segments it is not possible for ML2
plugins to know which VLAN to add on managed devices.
** 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/1967742
Title:
ML2 - Network Context, not possible to see original/current segments
Status in neutron:
New
Bug description:
When ML2 driver receive NetworkContext after adding network segment
with:
openstack network segment create \
--network e686a356-58d7-4cf0-bdf9-e720d9925ac0 \
--physical-network net3 \
--network-type vlan \
--segment 300 provision-net3
In `update_network_postcommit`, context.current and context.original
both include all segments:
context.current:
{'id': 'e686a356-58d7-4cf0-bdf9-e720d9925ac0',
'name': 'routed_provider_net',
'segments': [
{'provider:network_type': 'vlan',
'provider:physical_network': 'net1',
'provider:segmentation_id': 100},
{'provider:network_type': 'vlan',
'provider:physical_network': 'net2',
'provider:segmentation_id': 200},
{'provider:network_type': 'vlan',
'provider:physical_network': 'net3',
'provider:segmentation_id': 300}]}
context.original:
{'id': 'e686a356-58d7-4cf0-bdf9-e720d9925ac0',
'name': 'routed_provider_net',
'segments': [
{'provider:network_type': 'vlan',
'provider:physical_network': 'net1',
'provider:segmentation_id': 100},
{'provider:network_type': 'vlan',
'provider:physical_network': 'net2',
'provider:segmentation_id': 200},
{'provider:network_type': 'vlan',
'provider:physical_network': 'net3',
'provi der:segmentation_id': 300}]}
Expected results:
context.orignial should not include the new segment on
physical_network: 'net3'.
Since both current and original include all segments it is not possible for
ML2 plugins to know which VLAN to add on managed devices.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1967742/+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 1959148] Re: cloud-init writes route6-$DEVICE config with a HEX netmask. ip route does not like : Error: inet6 prefix is expected rather than "fd00:fd00:fd00::/ffff:ffff:ffff:fff
** Also affects: nova Importance: Undecided Status: New -- 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/1959148 Title: cloud-init writes route6-$DEVICE config with a HEX netmask. ip route does not like : Error: inet6 prefix is expected rather than "fd00:fd00:fd00::/:::::". Status in cloud-init: In Progress Status in OpenStack Compute (nova): New Bug description: Description of problem: The routes put in route6-$DEVICE by cloud-init is in an invalid format. The schema[1] for network_matadata uses a non-converntinal format for the IPv6 netmask. It is stored as an IPv6 address, similar to how IPv4 netmasks are written 255.255.255.0 the IPv6 netmask is written as ::::: in the network metadata. cloud-init does not translate this. So you end up with: cat /etc/sysconfig/network-scripts/route6-ens3 # Created by cloud-init on instance boot automatically, do not edit. # ::/:: via fd00:fd00:fd00:2::fffe dev ens3 fd00:fd00:fd00:1::/::::: via fd00:fd00:fd00:2::fffe dev ens3 fd00:fd00:fd00::/::::: via fd00:fd00:fd00:2::fffe dev ens3 The result is that the routes are ignored since it is not a valid inet6 prefix. [1] https://docs.openstack.org/nova/latest/_downloads/9119ca7ac90aa2990e762c08baea3a36/network_data.json Actual results: Jan 26 14:12:45 overcloud-novacompute-0 NetworkManager[1027]: [1643206365.7973] ifcfg-rh: ignoring invalid route at "::/:: via fd00:fd00:fd00:2::fffe dev ens3" (/etc/sysconfig/network-scripts/route6-ens3:3): Argument for "::/::" is not ADDR/PREFIX format Jan 26 14:12:45 overcloud-novacompute-0 NetworkManager[1027]: [1643206365.7977] ifcfg-rh: ignoring invalid route at "fd00:fd00:fd00:1::/::::: via fd00:fd00:fd00:2::fffe dev ens3" (/etc/sysconfig/network-scripts/route6-ens3:4): Argument for "fd00:fd00:fd00:1::/:::::" is not ADDR/PREFIX format Jan 26 14:12:45 overcloud-novacompute-0 NetworkManager[1027]: [1643206365.7979] ifcfg-rh: ignoring invalid route at "fd00:fd00:fd00::/::::: via fd00:fd00:fd00:2::fffe dev ens3" (/etc/sysconfig/network-scripts/route6-ens3:5): Argument for "fd00:fd00:fd00::/:::::" is not ADDR/PREFIX format ip -6 route add fd00:fd00:fd00::/::::: via fd00:fd00:fd00::1 Error: inet6 prefix is expected rather than "fd00:fd00:fd00::/:::::". Expected results: The netmask should be the decimal number in CIDR annotation. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1959148/+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 1959148] [NEW] cloud-init writes route6-$DEVICE config with a HEX netmask. ip route does not like : Error: inet6 prefix is expected rather than "fd00:fd00:fd00::/ffff:ffff:ffff:f
Public bug reported: Description of problem: The routes put in route6-$DEVICE by cloud-init is in an invalid format. The schema[1] for network_matadata uses a non-converntinal format for the IPv6 netmask. It is stored as an IPv6 address, similar to how IPv4 netmasks are written 255.255.255.0 the IPv6 netmask is written as ::::: in the network metadata. cloud-init does not translate this. So you end up with: cat /etc/sysconfig/network-scripts/route6-ens3 # Created by cloud-init on instance boot automatically, do not edit. # ::/:: via fd00:fd00:fd00:2::fffe dev ens3 fd00:fd00:fd00:1::/::::: via fd00:fd00:fd00:2::fffe dev ens3 fd00:fd00:fd00::/::::: via fd00:fd00:fd00:2::fffe dev ens3 The result is that the routes are ignored since it is not a valid inet6 prefix. [1] https://docs.openstack.org/nova/latest/_downloads/9119ca7ac90aa2990e762c08baea3a36/network_data.json Actual results: Jan 26 14:12:45 overcloud-novacompute-0 NetworkManager[1027]: [1643206365.7973] ifcfg-rh: ignoring invalid route at "::/:: via fd00:fd00:fd00:2::fffe dev ens3" (/etc/sysconfig/network-scripts/route6-ens3:3): Argument for "::/::" is not ADDR/PREFIX format Jan 26 14:12:45 overcloud-novacompute-0 NetworkManager[1027]: [1643206365.7977] ifcfg-rh: ignoring invalid route at "fd00:fd00:fd00:1::/::::: via fd00:fd00:fd00:2::fffe dev ens3" (/etc/sysconfig/network-scripts/route6-ens3:4): Argument for "fd00:fd00:fd00:1::/:::::" is not ADDR/PREFIX format Jan 26 14:12:45 overcloud-novacompute-0 NetworkManager[1027]: [1643206365.7979] ifcfg-rh: ignoring invalid route at "fd00:fd00:fd00::/::::: via fd00:fd00:fd00:2::fffe dev ens3" (/etc/sysconfig/network-scripts/route6-ens3:5): Argument for "fd00:fd00:fd00::/:::::" is not ADDR/PREFIX format ip -6 route add fd00:fd00:fd00::/::::: via fd00:fd00:fd00::1 Error: inet6 prefix is expected rather than "fd00:fd00:fd00::/:::::". Expected results: The netmask should be the decimal number in CIDR annotation. ** Affects: cloud-init Importance: Undecided Status: New -- 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/1959148 Title: cloud-init writes route6-$DEVICE config with a HEX netmask. ip route does not like : Error: inet6 prefix is expected rather than "fd00:fd00:fd00::/:::::". Status in cloud-init: New Bug description: Description of problem: The routes put in route6-$DEVICE by cloud-init is in an invalid format. The schema[1] for network_matadata uses a non-converntinal format for the IPv6 netmask. It is stored as an IPv6 address, similar to how IPv4 netmasks are written 255.255.255.0 the IPv6 netmask is written as ::::: in the network metadata. cloud-init does not translate this. So you end up with: cat /etc/sysconfig/network-scripts/route6-ens3 # Created by cloud-init on instance boot automatically, do not edit. # ::/:: via fd00:fd00:fd00:2::fffe dev ens3 fd00:fd00:fd00:1::/::::: via fd00:fd00:fd00:2::fffe dev ens3 fd00:fd00:fd00::/::::: via fd00:fd00:fd00:2::fffe dev ens3 The result is that the routes are ignored since it is not a valid inet6 prefix. [1] https://docs.openstack.org/nova/latest/_downloads/9119ca7ac90aa2990e762c08baea3a36/network_data.json Actual results: Jan 26 14:12:45 overcloud-novacompute-0 NetworkManager[1027]: [1643206365.7973] ifcfg-rh: ignoring invalid route at "::/:: via fd00:fd00:fd00:2::fffe dev ens3" (/etc/sysconfig/network-scripts/route6-ens3:3): Argument for "::/::" is not ADDR/PREFIX format Jan 26 14:12:45 overcloud-novacompute-0 NetworkManager[1027]: [1643206365.7977] ifcfg-rh: ignoring invalid route at "fd00:fd00:fd00:1::/::::: via fd00:fd00:fd00:2::fffe dev ens3" (/etc/sysconfig/network-scripts/route6-ens3:4): Argument for "fd00:fd00:fd00:1::/:::::" is not ADDR/PREFIX format Jan 26 14:12:45 overcloud-novacompute-0 NetworkManager[1027]: [1643206365.7979] ifcfg-rh: ignoring invalid route at "fd00:fd00:fd00::/::::: via fd00:fd00:fd00:2::fffe dev ens3" (/etc/sysconfig/network-scripts/route6-ens3:5): Argument for "fd00:fd00:fd00::/:::::" is not ADDR/PREFIX format ip -6 route add fd00:fd00:fd00::/::::: via fd00:fd00:fd00::1 Error: inet6 prefix is expected rather than "fd00:fd00:fd00::/:::::". Expected results: The netmask should be the decimal number in CIDR annotation. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1959148/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : ht
[Yahoo-eng-team] [Bug 1956785] [NEW] Duplicate validator TypeError for dict values
Public bug reported:
In the below logs I observe that a port update is attempted with
duplicate extra_dhcp_opts. Since the values for extra_dhcp_opts are
dicts the _collect_duplicates() method[1] fails as it attempts to add
dict's to a set.
[1] https://opendev.org/openstack/neutron-
lib/src/branch/master/neutron_lib/api/validators/__init__.py#L76-L91
2022-01-07 12:18:22.854 27 DEBUG neutron.api.v2.base
[req-67d0c767-16c3-4bd6-8c7d-455becccaa96 - fake_project_id - - -] Request
body: {'port': {'extra_dhcp_opts': [{'opt_name': 'tag:!ipxe6,59', 'opt_value':
'tftp://[fd00:fd00:fd00::1]/undionly.kpxe', 'ip_version': 6}, {'opt_name':
'tag:ipxe6,59', 'opt_value': 'http://[fd00:fd00:fd00::1]:8088/boot.ipxe',
'ip_version': 6}, {'opt_name': 'tag:!ipxe6,59', 'opt_value':
'tftp://[fd00:fd00:fd00::1]/undionly.kpxe', 'ip_version': 6}, {'opt_name':
'tag:ipxe6,59', 'opt_value': 'http://[fd00:fd00:fd00::1]:8088/boot.ipxe',
'ip_version': 6}, {'opt_name': 'tag:!ipxe6,59', 'opt_value':
'tftp://[fd00:fd00:fd00::1]/undionly.kpxe', 'ip_version': 6}, {'opt_name':
'tag:ipxe6,59', 'opt_value': 'http://[fd00:fd00:fd00::1]:8088/boot.ipxe',
'ip_version': 6}, {'opt_name': 'tag:!ipxe6,59', 'opt_value':
'tftp://[fd00:fd00:fd00::1]/undionly.kpxe', 'ip_version': 6}, {'opt_name':
'tag:ipxe6,59', 'opt_value': 'http://[fd00:fd00:fd00::1]:8088/boot.ipxe',
'ip_version': 6}]}} prepare_request_body
/usr/lib/python3.6/site-packages/neutron/api/v2/base.py:729
2022-01-07 12:18:22.856 27 WARNING neutron.pecan_wsgi.hooks.body_validation
[req-67d0c767-16c3-4bd6-8c7d-455becccaa96 - fake_project_id - - -] An exception
happened while processing the request body. The exception message is
[unhashable type: 'dict'].
2022-01-07 12:18:22.858 27 ERROR neutron.pecan_wsgi.hooks.translation
[req-67d0c767-16c3-4bd6-8c7d-455becccaa96 - fake_project_id - - -] PUT failed.:
TypeError: unhashable type: 'dict'
2022-01-07 12:18:22.858 27 ERROR neutron.pecan_wsgi.hooks.translation Traceback
(most recent call last):
2022-01-07 12:18:22.858 27 ERROR neutron.pecan_wsgi.hooks.translation File
"/usr/lib/python3.6/site-packages/pecan/core.py", line 682, in __call__
2022-01-07 12:18:22.858 27 ERROR neutron.pecan_wsgi.hooks.translation
controller, args, kwargs = self.find_controller(state)
2022-01-07 12:18:22.858 27 ERROR neutron.pecan_wsgi.hooks.translation File
"/usr/lib/python3.6/site-packages/pecan/core.py", line 858, in find_controller
2022-01-07 12:18:22.858 27 ERROR neutron.pecan_wsgi.hooks.translation
controller, args, kw = super(Pecan, self).find_controller(_state)
2022-01-07 12:18:22.858 27 ERROR neutron.pecan_wsgi.hooks.translation File
"/usr/lib/python3.6/site-packages/pecan/core.py", line 550, in find_controller
2022-01-07 12:18:22.858 27 ERROR neutron.pecan_wsgi.hooks.translation
self.handle_hooks(self.determine_hooks(controller), 'before', state)
2022-01-07 12:18:22.858 27 ERROR neutron.pecan_wsgi.hooks.translation File
"/usr/lib/python3.6/site-packages/pecan/core.py", line 865, in handle_hooks
2022-01-07 12:18:22.858 27 ERROR neutron.pecan_wsgi.hooks.translation
return super(Pecan, self).handle_hooks(hooks, *args, **kw)
2022-01-07 12:18:22.858 27 ERROR neutron.pecan_wsgi.hooks.translation File
"/usr/lib/python3.6/site-packages/pecan/core.py", line 342, in handle_hooks
2022-01-07 12:18:22.858 27 ERROR neutron.pecan_wsgi.hooks.translation
result = getattr(hook, hook_type)(*args)
2022-01-07 12:18:22.858 27 ERROR neutron.pecan_wsgi.hooks.translation File
"/usr/lib/python3.6/site-packages/neutron/pecan_wsgi/hooks/body_validation.py",
line 71, in before
2022-01-07 12:18:22.858 27 ERROR neutron.pecan_wsgi.hooks.translation raise
e
2022-01-07 12:18:22.858 27 ERROR neutron.pecan_wsgi.hooks.translation File
"/usr/lib/python3.6/site-packages/neutron/pecan_wsgi/hooks/body_validation.py",
line 67, in before
2022-01-07 12:18:22.858 27 ERROR neutron.pecan_wsgi.hooks.translation
allow_bulk=is_create)
2022-01-07 12:18:22.858 27 ERROR neutron.pecan_wsgi.hooks.translation File
"/usr/lib/python3.6/site-packages/neutron/api/v2/base.py", line 776, in
prepare_request_body
2022-01-07 12:18:22.858 27 ERROR neutron.pecan_wsgi.hooks.translation
attr_ops.convert_values(res_dict, exc_cls=webob.exc.HTTPBadRequest)
2022-01-07 12:18:22.858 27 ERROR neutron.pecan_wsgi.hooks.translation File
"/usr/lib/python3.6/site-packages/neutron_lib/api/attributes.py", line 233, in
convert_values
2022-01-07 12:18:22.858 27 ERROR neutron.pecan_wsgi.hooks.translation
attr_vals['validate'][rule])
2022-01-07 12:18:22.858 27 ERROR neutron.pecan_wsgi.hooks.translation File
"/usr/lib/python3.6/site-packages/neutron_lib/api/validators/__init__.py", line
513, in validate_any_key_specs_or_none
2022-01-07 12:18:22.858 27 ERROR neutron.pecan_wsgi.hooks.translation msg =
_validate_list_of_items(dict_validator, data)
2022-01-07 12:18:22.858 27 ERROR neutron.pecan_wsgi.hooks.translation File
"/usr/lib/python3.6/sit
[Yahoo-eng-team] [Bug 1921713] [NEW] Strings in tags field is limited to 60 chars
Public bug reported: I have a usecase where we need to put a hostname in the tags field. This fails for hosts with very long hostnames because the tags elemtents are limited to 60 character strings. Invalid input for operation: 'tripleo_hostname=centos-8-stream-vexxhost- ca-ymq-1-0023709342' exceeds maximum length of 60." Let's increase the field to allow 255 characters. ** 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/1921713 Title: Strings in tags field is limited to 60 chars Status in neutron: New Bug description: I have a usecase where we need to put a hostname in the tags field. This fails for hosts with very long hostnames because the tags elemtents are limited to 60 character strings. Invalid input for operation: 'tripleo_hostname=centos-8-stream- vexxhost-ca-ymq-1-0023709342' exceeds maximum length of 60." Let's increase the field to allow 255 characters. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1921713/+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 1868724] [NEW] KeyError 'gateway_ip' in neutron/services/segments/plugin.py
Public bug reported: 2020-03-24 00:12:05.019 35 ERROR neutron_lib.callbacks.manager [req-be6ef908-8d3c-4e20-84b5-80ef1d8ab94e 8a8ad2f8e3f7478b8ce5e84f620cb4db 255eb2ea84ed4b29a55aceffcecf2a5d - default default] Error during notification for neutron.services.segments.plugin.NovaSegmentNotifier._notify_subnet_deleted--9223372036853509478 subnet, after_delete: KeyError: 'gateway_ip' 2020-03-24 00:12:05.019 35 ERROR neutron_lib.callbacks.manager Traceback (most recent call last): 2020-03-24 00:12:05.019 35 ERROR neutron_lib.callbacks.manager File "/usr/lib/python2.7/site-packages/neutron_lib/callbacks/manager.py", line 197, in _notify_loop 2020-03-24 00:12:05.019 35 ERROR neutron_lib.callbacks.manager callback(resource, event, trigger, **kwargs) 2020-03-24 00:12:05.019 35 ERROR neutron_lib.callbacks.manager File "/usr/lib/python2.7/site-packages/neutron/services/segments/plugin.py", line 321, in _notify_subnet_deleted 2020-03-24 00:12:05.019 35 ERROR neutron_lib.callbacks.manager total, reserved = self._calculate_inventory_total_and_reserved(subnet) 2020-03-24 00:12:05.019 35 ERROR neutron_lib.callbacks.manager File "/usr/lib/python2.7/site-packages/neutron/services/segments/plugin.py", line 271, in _calculate_inventory_total_and_reserved 2020-03-24 00:12:05.019 35 ERROR neutron_lib.callbacks.manager if subnet['gateway_ip']: 2020-03-24 00:12:05.019 35 ERROR neutron_lib.callbacks.manager KeyError: 'gateway_ip' 2020-03-24 00:12:05.019 35 ERROR neutron_lib.callbacks.manager 2020-03-24 00:12:05.020 35 ERROR neutron_lib.callbacks.manager [req-be6ef908-8d3c-4e20-84b5-80ef1d8ab94e 8a8ad2f8e3f7478b8ce5e84f620cb4db 255eb2ea84ed4b29a55aceffcecf2a5d - default default] Error during notification for neutron.services.segments.plugin.NovaSegmentNotifier._notify_subnet_deleted--9223372036852953322 subnet, after_delete: KeyError: 'gateway_ip' 2020-03-24 00:12:05.020 35 ERROR neutron_lib.callbacks.manager Traceback (most recent call last): 2020-03-24 00:12:05.020 35 ERROR neutron_lib.callbacks.manager File "/usr/lib/python2.7/site-packages/neutron_lib/callbacks/manager.py", line 197, in _notify_loop 2020-03-24 00:12:05.020 35 ERROR neutron_lib.callbacks.manager callback(resource, event, trigger, **kwargs) 2020-03-24 00:12:05.020 35 ERROR neutron_lib.callbacks.manager File "/usr/lib/python2.7/site-packages/neutron/services/segments/plugin.py", line 321, in _notify_subnet_deleted 2020-03-24 00:12:05.020 35 ERROR neutron_lib.callbacks.manager total, reserved = self._calculate_inventory_total_and_reserved(subnet) 2020-03-24 00:12:05.020 35 ERROR neutron_lib.callbacks.manager File "/usr/lib/python2.7/site-packages/neutron/services/segments/plugin.py", line 271, in _calculate_inventory_total_and_reserved 2020-03-24 00:12:05.020 35 ERROR neutron_lib.callbacks.manager if subnet['gateway_ip']: 2020-03-24 00:12:05.020 35 ERROR neutron_lib.callbacks.manager KeyError: 'gateway_ip' 2020-03-24 00:12:05.020 35 ERROR neutron_lib.callbacks.manager ** 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/1868724 Title: KeyError 'gateway_ip' in neutron/services/segments/plugin.py Status in neutron: New Bug description: 2020-03-24 00:12:05.019 35 ERROR neutron_lib.callbacks.manager [req-be6ef908-8d3c-4e20-84b5-80ef1d8ab94e 8a8ad2f8e3f7478b8ce5e84f620cb4db 255eb2ea84ed4b29a55aceffcecf2a5d - default default] Error during notification for neutron.services.segments.plugin.NovaSegmentNotifier._notify_subnet_deleted--9223372036853509478 subnet, after_delete: KeyError: 'gateway_ip' 2020-03-24 00:12:05.019 35 ERROR neutron_lib.callbacks.manager Traceback (most recent call last): 2020-03-24 00:12:05.019 35 ERROR neutron_lib.callbacks.manager File "/usr/lib/python2.7/site-packages/neutron_lib/callbacks/manager.py", line 197, in _notify_loop 2020-03-24 00:12:05.019 35 ERROR neutron_lib.callbacks.manager callback(resource, event, trigger, **kwargs) 2020-03-24 00:12:05.019 35 ERROR neutron_lib.callbacks.manager File "/usr/lib/python2.7/site-packages/neutron/services/segments/plugin.py", line 321, in _notify_subnet_deleted 2020-03-24 00:12:05.019 35 ERROR neutron_lib.callbacks.manager total, reserved = self._calculate_inventory_total_and_reserved(subnet) 2020-03-24 00:12:05.019 35 ERROR neutron_lib.callbacks.manager File "/usr/lib/python2.7/site-packages/neutron/services/segments/plugin.py", line 271, in _calculate_inventory_total_and_reserved 2020-03-24 00:12:05.019 35 ERROR neutron_lib.callbacks.manager if subnet['gateway_ip']: 2020-03-24 00:12:05.019 35 ERROR neutron_lib.callbacks.manager KeyError: 'gateway_ip' 2020-03-24 00:12:05.019 35 ERROR neu
[Yahoo-eng-team] [Bug 1865138] [NEW] When deleting an stateless subnet port can get allocation on subnet with invalid segment
Public bug reported: A provider network with 3 stateless subnet, on different segments. (NOTE, this output is from a dev environment with WIP fixes for bug/1864333 and bug/1864333) $ for subnet in $(openstack subnet list --network providernet -f value -c ID); do openstack subnet show $subnet -f yaml -c segment_id -c cidr -c id; done cidr: deaf:beef:3::/64 id: 954a1b8c-5fe7-4dcc-84bd-df24c371e651 segment_id: 632b2bab-5402-4a4d-9433-783d7051d8aa cidr: deaf:beef:1::/64 id: ebae0025-a701-4b22-aa66-00ec48025b30 segment_id: d1930254-36c9-4490-94f7-d095a25cf3b0 cidr: deaf:beef:2::/64 id: ec2a9675-a286-4c8b-983d-2f762939cb5b segment_id: 1586a525-e250-4003-bae4-819e18e70c0e $ openstack port list --network providernet -f yaml -c "Fixed IP Addresses" - Fixed IP Addresses: - ip_address: deaf:beef:2:0:f816:3eff:fe03:eb71 subnet_id: ec2a9675-a286-4c8b-983d-2f762939cb5b - Fixed IP Addresses: - ip_address: deaf:beef:3:0:f816:3eff:fe48:bb26 subnet_id: c052289a-f8a0-464b-9413-717628fca4c2 - Fixed IP Addresses: - ip_address: deaf:beef:1:0:f816:3eff:fea1:1aab subnet_id: ebae0025-a701-4b22-aa66-00ec48025b30 - Fixed IP Addresses: [] <-- Deffered allocation $ openstack subnet delete subnet3 After deleting subnet3, the port who was on this subnet get's an allocation on subnet_id: ebae0025-a701-4b22-aa66-00ec48025b30 which is not the correct segment for this host. $ openstack port list --network providernet -f yaml -c "Fixed IP Addresses" - Fixed IP Addresses: - ip_address: deaf:beef:2:0:f816:3eff:fe03:eb71 subnet_id: ec2a9675-a286-4c8b-983d-2f762939cb5b - Fixed IP Addresses: - ip_address: deaf:beef:1:0:f816:3eff:fe48:bb26 <-- Allocation on invalid segment. subnet_id: ebae0025-a701-4b22-aa66-00ec48025b30 - Fixed IP Addresses: - ip_address: deaf:beef:1:0:f816:3eff:fea1:1aab subnet_id: ebae0025-a701-4b22-aa66-00ec48025b30 - Fixed IP Addresses: [] I belive the correct behaviour here would be to remove the allocation from the deleted segment and set allocaton 'deferred' on the port. Or raise SubnetInUse exception on subnet delete because there is no other auto-address subnet that can satisfy the in-use port. ** Affects: neutron Importance: Undecided Status: New ** Tags: ipv6 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1865138 Title: When deleting an stateless subnet port can get allocation on subnet with invalid segment Status in neutron: New Bug description: A provider network with 3 stateless subnet, on different segments. (NOTE, this output is from a dev environment with WIP fixes for bug/1864333 and bug/1864333) $ for subnet in $(openstack subnet list --network providernet -f value -c ID); do openstack subnet show $subnet -f yaml -c segment_id -c cidr -c id; done cidr: deaf:beef:3::/64 id: 954a1b8c-5fe7-4dcc-84bd-df24c371e651 segment_id: 632b2bab-5402-4a4d-9433-783d7051d8aa cidr: deaf:beef:1::/64 id: ebae0025-a701-4b22-aa66-00ec48025b30 segment_id: d1930254-36c9-4490-94f7-d095a25cf3b0 cidr: deaf:beef:2::/64 id: ec2a9675-a286-4c8b-983d-2f762939cb5b segment_id: 1586a525-e250-4003-bae4-819e18e70c0e $ openstack port list --network providernet -f yaml -c "Fixed IP Addresses" - Fixed IP Addresses: - ip_address: deaf:beef:2:0:f816:3eff:fe03:eb71 subnet_id: ec2a9675-a286-4c8b-983d-2f762939cb5b - Fixed IP Addresses: - ip_address: deaf:beef:3:0:f816:3eff:fe48:bb26 subnet_id: c052289a-f8a0-464b-9413-717628fca4c2 - Fixed IP Addresses: - ip_address: deaf:beef:1:0:f816:3eff:fea1:1aab subnet_id: ebae0025-a701-4b22-aa66-00ec48025b30 - Fixed IP Addresses: [] <-- Deffered allocation $ openstack subnet delete subnet3 After deleting subnet3, the port who was on this subnet get's an allocation on subnet_id: ebae0025-a701-4b22-aa66-00ec48025b30 which is not the correct segment for this host. $ openstack port list --network providernet -f yaml -c "Fixed IP Addresses" - Fixed IP Addresses: - ip_address: deaf:beef:2:0:f816:3eff:fe03:eb71 subnet_id: ec2a9675-a286-4c8b-983d-2f762939cb5b - Fixed IP Addresses: - ip_address: deaf:beef:1:0:f816:3eff:fe48:bb26 <-- Allocation on invalid segment. subnet_id: ebae0025-a701-4b22-aa66-00ec48025b30 - Fixed IP Addresses: - ip_address: deaf:beef:1:0:f816:3eff:fea1:1aab subnet_id: ebae0025-a701-4b22-aa66-00ec48025b30 - Fixed IP Addresses: [] I belive the correct behaviour here would be to remove the allocation from the deleted segment and set allocaton 'deferred' on the port. Or raise SubnetInUse exception on subnet delete because there is no other auto-address subnet that can satisfy the in-use port. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1865138/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.la
[Yahoo-eng-team] [Bug 1865098] [NEW] logging error in _update_routed_network_host_routes
Public bug reported:
File "/opt/stack/neutron/neutron/services/segments/plugin.py", line 556, in
_update_routed_network_host_routes
(subnet.id, subnet.network_id))
Message: "Error formatting log line msg='Updating host routes for subnet *s on
routed network *s' err=TypeError('not enough arguments for format string',)"
Arguments: (('ebae0025-a701-4b22-aa66-00ec48025b30',
'306a1697-03a2-4445-bc78-c874fe226ffd'),)
--- Logging error ---
** Affects: neutron
Importance: Undecided
Status: New
** Tags: logging
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1865098
Title:
logging error in _update_routed_network_host_routes
Status in neutron:
New
Bug description:
File "/opt/stack/neutron/neutron/services/segments/plugin.py", line 556, in
_update_routed_network_host_routes
(subnet.id, subnet.network_id))
Message: "Error formatting log line msg='Updating host routes for subnet *s
on routed network *s' err=TypeError('not enough arguments for format string',)"
Arguments: (('ebae0025-a701-4b22-aa66-00ec48025b30',
'306a1697-03a2-4445-bc78-c874fe226ffd'),)
--- Logging error ---
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1865098/+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 1864333] [NEW] When adding another stateless subnet, implicit address allocation happen for port with deferred ip allocation
Public bug reported:
$ openstack port create \
--network provider test-port-deferred \
-c fixed_ips -f yaml
fixed_ips: []
$ openstack subnet create \
--ipv6-ra-mode dhcpv6-stateless \
--ipv6-address-mode dhcpv6-stateless \
--network provider \
--network-segment provider-segment2 \
--dhcp \
--ip-version 6 \
--subnet-range dead:beef:3::/64 \
provider-subnet2-2
$ openstack subnet list --network provider -f yaml
- ID: 793bf8ce-f44a-468f-83e0-6c82375081f7
Name: provider-subnet2-2
Network: 45b993b2-5224-409e-9756-0be190a19cf5
Subnet: dead:beef:3::/64
- ID: 926269c1-b05e-4b48-bafe-6be8e9cbd12c
Name: provider-subnet1
Network: 45b993b2-5224-409e-9756-0be190a19cf5
Subnet: dead:beef:1::/64
- ID: cdec94ce-8e3b-4c5b-aba2-13271f8b8b91
Name: provider-subnet2
Network: 45b993b2-5224-409e-9756-0be190a19cf5
Subnet: dead:beef:2::/64
$ openstack port list --network provider -f yaml
- Fixed IP Addresses:
- ip_address: dead:beef:3:0:f816:3eff:fe9e:67f7
subnet_id: 793bf8ce-f44a-468f-83e0-6c82375081f7
ID: 8e2fe6e9-d418-4228-aad8-f5d0704be801
MAC Address: fa:16:3e:9e:67:f7
Name: test-port-deferred
Status: DOWN
$ openstack port show test-port-deferred -f yaml
admin_state_up: true
allowed_address_pairs: []
binding_host_id: ''
binding_profile: {}
binding_vif_details: {}
binding_vif_type: unbound
binding_vnic_type: normal
created_at: '2020-02-22T13:46:51Z'
data_plane_status: null
description: ''
device_id: ''
device_owner: ''
dns_assignment:
- fqdn: host-dead-beef-3-0-f816-3eff-fe9e-67f7.openstackgate.local.
hostname: host-dead-beef-3-0-f816-3eff-fe9e-67f7
ip_address: dead:beef:3:0:f816:3eff:fe9e:67f7
dns_domain: ''
dns_name: ''
extra_dhcp_opts: []
fixed_ips:
- ip_address: dead:beef:3:0:f816:3eff:fe9e:67f7
subnet_id: 793bf8ce-f44a-468f-83e0-6c82375081f7
id: 8e2fe6e9-d418-4228-aad8-f5d0704be801
location:
cloud: ''
project:
domain_id: default
domain_name: null
id: 09295b4e443245b6b491c79f283388b9
name: demo
region_name: RegionOne
zone: null
mac_address: fa:16:3e:9e:67:f7
name: test-port-deferred
network_id: 45b993b2-5224-409e-9756-0be190a19cf5
port_security_enabled: true
project_id: 09295b4e443245b6b491c79f283388b9
propagate_uplink_status: false
qos_network_policy_id: null
qos_policy_id: null
resource_request: null
revision_number: 3
security_group_ids:
- a19761db-e6a5-470c-a95f-98255e16b845
status: DOWN
tags: []
trunk_details: null
updated_at: '2020-02-22T13:47:12Z'
Since the port does not have 'binding_host_id' IP allocation on the
routed provider network was deffered on create. However when adding
another ipv6 stateless subnet, implicit address allocation is added to
the port. This allocation should have been deferred.
** Affects: neutron
Importance: Undecided
Status: New
** Summary changed:
- When adding another stateless subnet, implicit address allocation happen for
port wiht deffered ip allocation
+ When adding another stateless subnet, implicit address allocation happen for
port with deffered ip allocation
** Summary changed:
- When adding another stateless subnet, implicit address allocation happen for
port with deffered ip allocation
+ When adding another stateless subnet, implicit address allocation happen for
port with deferred ip allocation
** Description changed:
$ openstack port create \
- --network provider test-port-deferred \
- -c fixed_ips -f yaml
- fixed_ips: []
+ --network provider test-port-deferred \
+ -c fixed_ips -f yaml
+ fixed_ips: []
$ openstack subnet create \
- --ipv6-ra-mode dhcpv6-stateless \
- --ipv6-address-mode dhcpv6-stateless \
- --network provider \
- --network-segment provider-segment2 \
- --dhcp \
- --ip-version 6 \
- --subnet-range dead:beef:3::/64 \
- provider-subnet2-2
+ --ipv6-ra-mode dhcpv6-stateless \
+ --ipv6-address-mode dhcpv6-stateless \
+ --network provider \
+ --network-segment provider-segment2 \
+ --dhcp \
+ --ip-version 6 \
+ --subnet-range dead:beef:3::/64 \
+ provider-subnet2-2
$ openstack subnet list --network provider -f yaml
- ID: 793bf8ce-f44a-468f-83e0-6c82375081f7
- Name: provider-subnet2-2
- Network: 45b993b2-5224-409e-9756-0be190a19cf5
- Subnet: dead:beef:3::/64
+ Name: provider-subnet2-2
+ Network: 45b993b2-5224-409e-9756-0be190a19cf5
+ Subnet: dead:beef:3::/64
- ID: 926269c1-b05e-4b48-bafe-6be8e9cbd12c
- Name: provider-subnet1
- Network: 45b993b2-5224-409e-9756-0be190a19cf5
- Subnet: dead:beef:1::/64
+ Name: provider-subnet1
+ Network: 45b993b2-5224-409e-9756-0be190a19cf
[Yahoo-eng-team] [Bug 1864225] [NEW] IP allocation for stateless IPv6 does not filter on segment when fixed-ips contain a subnet_id
Public bug reported: Network 45b993b2-5224-409e-9756-0be190a19cf5 with two segments and two subnets: $ openstack network segment list --network provider -f yaml - ID: 612f96f0-7682-49f7-bfc2-c52437f6e948 Name: provider-segment1 Network: 45b993b2-5224-409e-9756-0be190a19cf5 Network Type: flat Segment: null - ID: 9632dc77-d8d1-4d2b-afab-23568f1d475f Name: provider-segment2 Network: 45b993b2-5224-409e-9756-0be190a19cf5 Network Type: flat Segment: null $ openstack subnet list --network provider -f yaml - ID: 926269c1-b05e-4b48-bafe-6be8e9cbd12c Name: provider-subnet1 Network: 45b993b2-5224-409e-9756-0be190a19cf5 Subnet: dead:beef:1::/64 - ID: cdec94ce-8e3b-4c5b-aba2-13271f8b8b91 Name: provider-subnet2 Network: 45b993b2-5224-409e-9756-0be190a19cf5 Subnet: dead:beef:2::/64 $ openstack subnet show -c segment_id -c ipv6_address_mode \ -c ipv6_ra_mode -c address_mode provider-subnet1 +---+--+ | Field | Value| +---+--+ | ipv6_address_mode | dhcpv6-stateless | | ipv6_ra_mode | dhcpv6-stateless | | segment_id| 612f96f0-7682-49f7-bfc2-c52437f6e948 | +---+--+ $ openstack subnet show -c segment_id -c ipv6_address_mode \ -c ipv6_ra_mode -c address_mode provider-subnet2 +---+--+ | Field | Value| +---+--+ | ipv6_address_mode | dhcpv6-stateless | | ipv6_ra_mode | dhcpv6-stateless | | segment_id| 9632dc77-d8d1-4d2b-afab-23568f1d475f | +---+--+ The two subnets have stateless address mode and are on different segments. When creating port, openstack port create --network provider test-port1 ip allocation is deffered because segments are used and no host id is provided. When creating a port with a subnet specified in fixed-ips the implicit address allocation for stateless subnets will allocate an address in both subnets. $ openstack port create --network provider \ --fixed-ip=subnet=provider-subnet1 test-port1 \ -c fixed_ips -f yaml fixed_ips: - ip_address: dead:beef:1:0:f816:3eff:fe9f:4907 subnet_id: 926269c1-b05e-4b48-bafe-6be8e9cbd12c - ip_address: dead:beef:2:0:f816:3eff:fe9f:4907 subnet_id: cdec94ce-8e3b-4c5b-aba2-13271f8b8b91 Upon trying to bind this port later as part of provisioning with Ironic, this fails because fixed_ips included invalid subnet. --- Failed to provision instance 3340fad9-93a6-4915-a87f-5f79cb647e03: Failed to prepare to deploy: Unable to set binding:host_id for neutron port c83d24aa-4167-4d37-9d1a-833290d55d83. Error: Invalid input for operation: Failed to create port on network 94543fd0-3a89-4d15-ad0c-ee1da99a63a4, because fixed_ips included invalid subnet 9c463bf7-0d6b-498e-a8b5-2c6c8bef7b56 --- This happens because all subnets are returned as candidates when fixed_ips is specified, despite that host id is not included: https://opendev.org/openstack/neutron/src/branch/master/neutron/objects/subnet.py#L330-L337 Then addresses for all stateless subnets in the candidates are allocated: https://opendev.org/openstack/neutron/src/branch/master/neutron/db/ipam_pluggable_backend.py#L256 ** 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/1864225 Title: IP allocation for stateless IPv6 does not filter on segment when fixed-ips contain a subnet_id Status in neutron: New Bug description: Network 45b993b2-5224-409e-9756-0be190a19cf5 with two segments and two subnets: $ openstack network segment list --network provider -f yaml - ID: 612f96f0-7682-49f7-bfc2-c52437f6e948 Name: provider-segment1 Network: 45b993b2-5224-409e-9756-0be190a19cf5 Network Type: flat Segment: null - ID: 9632dc77-d8d1-4d2b-afab-23568f1d475f Name: provider-segment2 Network: 45b993b2-5224-409e-9756-0be190a19cf5 Network Type: flat Segment: null $ openstack subnet list --network provider -f yaml - ID: 926269c1-b05e-4b48-bafe-6be8e9cbd12c Name: provider-subnet1 Network: 45b993b2-5224-409e-9756-0be190a19cf5 Subnet: dead:beef:1::/64 - ID: cdec94ce-8e3b-4c5b-aba2-13271f8b8b91 Name: provider-subnet2 Network: 45b993b2-5224-409e-9756-0be190a19cf5 Subnet: dead:beef:2::/64 $ openstack subnet show -c segment_id -c ipv6_address_mode \ -c ipv6_ra_mode -c address_mode provider-subnet1 +---+--+ | Field | Value| +---+-
[Yahoo-eng-team] [Bug 1861032] [NEW] [RFE] Add support for configuring dnsmasq with multiple IPv6 addresses in same subnet on same port
Public bug reported:
To enable network boot and Ironic provisioning a patch has been proposed
to dnsmasq. The patch add's the possibility to provide list's of
individual addresses as well as prefixed ranges of ipv6 addresses for a
dhcp-host reservation.
When dnsmasq recieve a request matching the clid or mac address is
recieved the server will iterate over all candidate addresses until it
find's one that is not already leased to a different clid/iaid and
advertise this address.
Using multiple reservations for a single host makes it possible to
maintain a static leases only configuration which support network
booting systems with UEFI firmware that request a new address (a new
SOLICIT with a new IA_NA option using a new IAID) for different boot
modes, for instance 'PXE over IPv6', and 'HTTP-Boot over IPv6'. Open
Virtual Machine Firmware (OVMF) and most UEFI firmware build on the EDK2
code base exhibit this behaviour.
A new configuration syntax is introduces in dnsmasq in patch:
http://lists.thekelleys.org.uk/pipermail/dnsmasq-
discuss/2020q1/013743.html
For example:
--dhcp-host=52:54:00:3f:5c:c0,[fd12:3456::aa02][fd12:3456::aa04],host1
The above will make the two addresses fd12:3456::aa02 and
fd12:3456::aa04 available to the host with hardware address
52:54:00:3f:5c:c0.
This RFE is to add functionality to the dnsmasq dhcp-agent implementation to
write the new configuration format in the dnsmasq hosts file.
Given a neutron port:
"ports": [
{
"dns_assignment": [
{
"hostname": "myport02",
"ip_address": "fd12:3456::aa02",
"fqdn": "myport02.my-domain.org"
},
{
"hostname": "myport04",
"ip_address": "fd12:3456::aa04",
"fqdn": "myport04.my-domain.org"
},
],
"fixed_ips": [
{
"ip_address": "fd12:3456::aa02",
"subnet_id": "008ba151-0b8c-4a67-98b5-0d2b87666062"
},
{
"ip_address": "fd12:3456::aa04",
"subnet_id": "008ba151-0b8c-4a67-98b5-0d2b87666062"
}
],
"id": "d80b1a3b-4fc1-49f3-952e-1e2ab7081d8b",
"mac_address": "fa:16:3e:58:42:ed",
"network_id": "70c1db1f-b701-45bd-96e0-a313ee3430b3",
},
]
}
Current behaviour
-
dhcp-host=fa:16:3e:58:42:ed,myport02.my-domain.org,[fd12:3456::aa02]
dhcp-host=fa:16:3e:58:42:ed,myport04.my-domain.org,[fd12:3456::aa04]
NOTE, this configuration means dnsmasq will only ever lease
fd12:3456::aa04. As it will always find that as the first valid
configuration for mac fa:16:3e:58:42:ed. In other words, the _current
behaviour is broken_.
New behaviour
-
dhcp-host=fa:16:3e:58:42:ed,myport02.my-domain.org,[fd12:3456::aa02][fd12:3456::aa04]
This will allow dnsmasq to lase both addresses when requests from the
client mac using different IAID's is recieved.
** Affects: neutron
Importance: Undecided
Assignee: Harald Jensås (harald-jensas)
Status: In Progress
** Tags: rfe
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1861032
Title:
[RFE] Add support for configuring dnsmasq with multiple IPv6 addresses
in same subnet on same port
Status in neutron:
In Progress
Bug description:
To enable network boot and Ironic provisioning a patch has been
proposed to dnsmasq. The patch add's the possibility to provide list's
of individual addresses as well as prefixed ranges of ipv6 addresses
for a dhcp-host reservation.
When dnsmasq recieve a request matching the clid or mac address is
recieved the server will iterate over all candidate addresses until it
find's one that is not already leased to a different clid/iaid and
advertise this address.
Using multiple reservations for a single host makes it possible to
maintain a static leases only configuration which support network
booting systems with UEFI firmware that request a new address (a new
SOLICIT with a new IA_NA option using a new IAID) for different boot
modes, for instance 'PXE over IPv6', and 'HTTP-Boot over IPv6'. Open
Virtual Machine Firmware (OVMF) and most UEFI firmware build on the
EDK2 code base exhibit this behaviour.
A new configuration syntax is introduces in dnsmasq in patch:
http://lists.thekelleys.org.uk/pipermail/dnsmasq-
discuss/202
[Yahoo-eng-team] [Bug 1861027] [NEW] neutron-lib - api-ref - port dns_assignment is a list?
Public bug reported:
In the api reference documentation dns_assignment is documented as:
"dns_assignment": {
"hostname": "myport",
"ip_address": "172.24.4.2",
"fqdn": "myport.my-domain.org"
},
Is it not in actually a list?
"dns_assignment": [
{
"hostname": "myport",
"ip_address": "172.24.4.2",
"fqdn": "myport.my-domain.org"
}
]
https://opendev.org/openstack/neutron-lib/src/branch/master/api-
ref/source/v2/samples/ports/ports-list-response.json#L11-L15
** Affects: neutron
Importance: Undecided
Status: New
** Tags: api-ref
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1861027
Title:
neutron-lib - api-ref - port dns_assignment is a list?
Status in neutron:
New
Bug description:
In the api reference documentation dns_assignment is documented as:
"dns_assignment": {
"hostname": "myport",
"ip_address": "172.24.4.2",
"fqdn": "myport.my-domain.org"
},
Is it not in actually a list?
"dns_assignment": [
{
"hostname": "myport",
"ip_address": "172.24.4.2",
"fqdn": "myport.my-domain.org"
}
]
https://opendev.org/openstack/neutron-lib/src/branch/master/api-
ref/source/v2/samples/ports/ports-list-response.json#L11-L15
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1861027/+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 1844124] Re: Not possible to change fixed-ips if port is on routed provider network
This was fixed in neutron. We can close this in tripleo.
** Changed in: tripleo
Status: Triaged => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1844124
Title:
Not possible to change fixed-ips if port is on routed provider network
Status in neutron:
Fix Released
Status in tripleo:
Fix Released
Bug description:
For ports on normal networks (non-Routed Provider Networks) it is
possible to change the fixed-ip of a port. When a port is on a Routed
Provider Network the same operation return an error: "Invalid input
for operation: IP allocation requires subnets for network." Since this
is an unbound port, and the change does not move the port ip
allocation to a subnet associated with a different segment this
operation should succeed.
$ grep flat_networks /etc/neutron/plugins/ml2/ml2_conf.ini
flat_networks = public,mynetwork
$ openstack network create \
--provider-network-type flat \
--provider-physical-network mynetwork \
mynetwork
$ openstack subnet create \
--network mynetwork \
--network-segment $(openstack network segment list --network mynetwork -f
value -c ID) \
--subnet-range 192.168.254.0/24 \
--allocation-pool start=192.168.254.10,end=192.168.254.100 \
mysubnet
$ openstack network show mynetwork -f value -c id && openstack subnet show
mysubnet -f value -c id
57e622a0-3003-4d9f-b01e-c12613935265
df2cbb56-12b9-4156-8a23-36023b110b75
$ curl -s -X POST \
-H "X-Auth-Token: $(openstack token issue -f value -c id)" \
http://192.168.122.222:9696/v2.0/ports \
-d '{"port": {"name": "test-port", "network_id":
"57e622a0-3003-4d9f-b01e-c12613935265", "fixed_ips": [{"subnet_id":
"df2cbb56-12b9-4156-8a23-36023b110b75"}]}}' \
| python -m json.tool
{
"port": {
"admin_state_up": true,
"allowed_address_pairs": [],
"binding:host_id": "",
"binding:profile": {},
"binding:vif_details": {},
"binding:vif_type": "unbound",
"binding:vnic_type": "normal",
"created_at": "2019-09-16T11:56:06Z",
"description": "",
"device_id": "",
"device_owner": "",
"dns_assignment": [
{
"fqdn": "host-192-168-254-44.openstackgate.local.",
"hostname": "host-192-168-254-44",
"ip_address": "192.168.254.44"
}
],
"dns_domain": "",
"dns_name": "",
"extra_dhcp_opts": [],
"fixed_ips": [
{
"ip_address": "192.168.254.44",
"subnet_id": "df2cbb56-12b9-4156-8a23-36023b110b75"
}
],
"id": "84ef332d-8c48-422a-b400-0655702b1a0e",
"ip_allocation": "immediate",
"mac_address": "fa:16:3e:43:7c:fe",
"name": "test-port",
"network_id": "57e622a0-3003-4d9f-b01e-c12613935265",
"port_security_enabled": true,
"project_id": "4abf7cb77b574734adf086dfa828cd84",
"propagate_uplink_status": false,
"qos_policy_id": null,
"resource_request": null,
"revision_number": 1,
"security_groups": [
"708b5fa0-244c-46ee-9b35-30ba45a71ccf"
],
"status": "DOWN",
"tags": [],
"tenant_id": "4abf7cb77b574734adf086dfa828cd84",
"updated_at": "2019-09-16T11:56:06Z"
}
}
$ curl -s -X PUT \
-H "X-Auth-Token: $(openstack token issue -f value -c id)" \
http://192.168.122.222:9696/v2.0/ports/84ef332d-8c48-422a-b400-0655702b1a0e \
-d '{"port": {"fixed_ips": [{"ip_address": "192.168.254.100"}]}}' \
| python -m json.tool
{
"NeutronError": {
"detail": "",
"message": "Invalid input for operation: IP allocation requires
subnets for network.",
"type": "InvalidInput"
}
}
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1844124/+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 1855854] [NEW] [RFE] Dynamic DHCP allocation pool
Public bug reported: Neuton currently only support configuring the DHCP agent with static /fixed-address allocations. The DHCP client id (the client MAC address in neutron's case) is mapped to a specific IP address in the dhcp server configuration. No range of addresses are made available for clients without a pre-allocated fixed-address. When network booting on IPv6 this become an issue, the DHCPv6 specification which mandetes use of the DHCP Unique Identifier (DUID) and Identity Association Identifier (IAID) to identify a lease. When network booting, an instance will move trough a minimum of two DHCP clients, and these rareley end up using identical DUID's and IAID's. The combination of static/fixed-address allocations in the DHCP server and the changeing DUID/IAID of the clients causes the second DHCP client request to get a ``no address available`` reply from the server, and thus the network boot process errors. NOTE: In some cases just the UEFI PXE6 end up doing two cycles of DHCPv6 S.A.R.R (Solicit, Advertise, Request, Reply) with different IAID's. Because some UEFI firwmare use's a non-RFC compliant random generator for the IAID see bug: https://bugzilla.tianocore.org/show_bug.cgi?id=1518. While this is a bug in UEFI firmware, it's a common enough implementation that is used by various hardware vendors that it makes sense to workaround the issue where possible. This RFE is for adding the possibility to make a subnet with dynamic allocation pool(s). This would solve the network booting issue with changing IAID's described above. A new lease with a new address will be offered during each step of network booting. For example an instance deployment via Openstack Baremetal service (ironic) would typically include three DHCP clients during provisioning: UEFI firmware, iPXE, ironic-python-agent ramdisk. So a toatal of 3 leases would be consumed to complete the provisioning. If this RFE is implemented, the dhcp server (dnsmasq) would configure the dhcp-range for a dynamic subnet (or dynamic allocation pool of a subnet) without the ``mode`` set to ``static``. To ensure that the dhcp server only provide a dynamic allocation for the desired ports the ``ignore`` option is used in a ``dhcp-host`` entry with a wildcard ``*`` host (``dhcp-host="*",ignore``). Ports that require dynamic addressing would get a ``dhcp-host`` entry with ``dhcp-host=`` (whithout the ``ignore``) so that these specific ports get addresses from the dynamic allocation pool. ** Affects: neutron Importance: Undecided Status: New ** Tags: rfe -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1855854 Title: [RFE] Dynamic DHCP allocation pool Status in neutron: New Bug description: Neuton currently only support configuring the DHCP agent with static /fixed-address allocations. The DHCP client id (the client MAC address in neutron's case) is mapped to a specific IP address in the dhcp server configuration. No range of addresses are made available for clients without a pre-allocated fixed-address. When network booting on IPv6 this become an issue, the DHCPv6 specification which mandetes use of the DHCP Unique Identifier (DUID) and Identity Association Identifier (IAID) to identify a lease. When network booting, an instance will move trough a minimum of two DHCP clients, and these rareley end up using identical DUID's and IAID's. The combination of static/fixed-address allocations in the DHCP server and the changeing DUID/IAID of the clients causes the second DHCP client request to get a ``no address available`` reply from the server, and thus the network boot process errors. NOTE: In some cases just the UEFI PXE6 end up doing two cycles of DHCPv6 S.A.R.R (Solicit, Advertise, Request, Reply) with different IAID's. Because some UEFI firwmare use's a non-RFC compliant random generator for the IAID see bug: https://bugzilla.tianocore.org/show_bug.cgi?id=1518. While this is a bug in UEFI firmware, it's a common enough implementation that is used by various hardware vendors that it makes sense to workaround the issue where possible. This RFE is for adding the possibility to make a subnet with dynamic allocation pool(s). This would solve the network booting issue with changing IAID's described above. A new lease with a new address will be offered during each step of network booting. For example an instance deployment via Openstack Baremetal service (ironic) would typically include three DHCP clients during provisioning: UEFI firmware, iPXE, ironic-python-agent ramdisk. So a toatal of 3 leases would be consumed to complete the provisioning. If this RFE is implemented, the dhcp server (dnsmasq) would configure the dhcp-range for a dynamic subnet (or dynamic allocation pool of a subnet) without the ``mode`
[Yahoo-eng-team] [Bug 1848690] [NEW] subnet_is_ipv6() function does not work for types ipv6_dhcpv6-stateless|stateful
Public bug reported:
def subnet_is_ipv6(subnet):
"""Common helper for checking network_state subnets for ipv6."""
# 'static6' or 'dhcp6'
if subnet['type'].endswith('6'):
# This is a request for DHCPv6.
return True
elif subnet['type'] == 'static' and is_ipv6_addr(subnet.get('address')):
return True
return False
Function return false for ipv6_dhcpv6-stateless|stateful, the eni renderer does
not add '6' to 'inet' so it's rendered like: 'iface iface0 inet auto|dhcp' not
'iface iface0 inet6 auto|dhcp'
** Affects: cloud-init
Importance: Undecided
Status: New
--
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/1848690
Title:
subnet_is_ipv6() function does not work for types
ipv6_dhcpv6-stateless|stateful
Status in cloud-init:
New
Bug description:
def subnet_is_ipv6(subnet):
"""Common helper for checking network_state subnets for ipv6."""
# 'static6' or 'dhcp6'
if subnet['type'].endswith('6'):
# This is a request for DHCPv6.
return True
elif subnet['type'] == 'static' and is_ipv6_addr(subnet.get('address')):
return True
return False
Function return false for ipv6_dhcpv6-stateless|stateful, the eni renderer
does not add '6' to 'inet' so it's rendered like: 'iface iface0 inet auto|dhcp'
not 'iface iface0 inet6 auto|dhcp'
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1848690/+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 1847517] [NEW] cloudinit/net/sysconfig.py writed incorrect config for dhcp-stateless openstack subnets
Public bug reported:
$ openstack subnet show 48c8407b-7ef3-4047-82dd-ca6d671c2162 -c
ipv6_address_mode -c ipv6_ra_mode
+---+--+
| Field | Value|
+---+--+
| ipv6_address_mode | dhcpv6-stateless |
| ipv6_ra_mode | dhcpv6-stateless |
+---+--+
File: openstack/latest/network_data.json
{
"services": [
{
"type": "dns",
"address": "fd12:3456:789a:1::1"
}
],
"networks": [
{
"network_id": "cf79eea0-6196-45a0-b9f8-ff9dd95eaab3",
"type": "ipv6_dhcpv6-stateless",
"services": [
{
"type": "dns",
"address": "fd12:3456:789a:1::1"
}
],
"netmask": ":::::",
"link": "tap5910c6cc-2d",
"routes": [
{
"netmask": "::",
"network": "::",
"gateway": "fd12:3456:789a:1::fffe"
}
],
"ip_address": "fd12:3456:789a:1:f816:3eff:fee2:3aa3",
"id": "network0"
}
],
"links": [
{
"vif_id": "5910c6cc-2d6e-4a44-bf05-2accdefd0316",
"type": "phy",
"ethernet_mac_address": "fa:16:3e:73:0d:96",
"id": "tap5910c6cc-2d",
"mtu": 1450
}
]
}
Actual result
-
The network config forces the client to try dhcpv6, not stateless e.g slaac.
This fails when there is no DHCPv6 configured, or DHCPv6 is only configured to
provide advanced options such a bootfile-url etc.
# Created by cloud-init on instance boot automatically, do not edit.
#
BOOTPROTO=none
DEFROUTE=yes
DEVICE=eth0
DHCPV6C=yes
HWADDR=fa:16:3e:73:0d:96
IPV6INIT=yes
IPV6_DEFAULTGW=fd12:3456:789a:1::fffe
MTU=1450
ONBOOT=yes
TYPE=Ethernet
USERCTL=no
Expected result
---
The configuration written should differentiate between dhcp6-stateful and
dhcp6-stateless.
For dhcp6-stateless "DHCPV6C=yes" should be replaced by IPV6_AUTOCONF=yes as
shown in the example below.
# Created by cloud-init on instance boot automatically, do not edit.
#
BOOTPROTO=none
DEFROUTE=yes
DEVICE=eth0
IPV6_AUTOCONF=yes
HWADDR=fa:16:3e:73:0d:96
IPV6INIT=yes
IPV6_DEFAULTGW=fd12:3456:789a:1::fffe
MTU=1450
ONBOOT=yes
TYPE=Ethernet
USERCTL=no
The issue starts is in the following code[1]:
if 'dhcp' in network['type']:
t = 'dhcp6' if network['type'].startswith('ipv6') else 'dhcp4'
subnet.update({
'type': t,
})
This makes the assumption that 'ipv6_dhcpv6-stateless' and
'ipv6_dhcpv6-stateful' can be treated the same.
Then in the code[2] the subnet type is checked and DHCPV6C is always used.
if subnet_type == 'dhcp6':
# TODO need to set BOOTPROTO to dhcp6 on SUSE
iface_cfg['IPV6INIT'] = True
iface_cfg['DHCPV6C'] = True
Grepping the source code it looks like this is only affecting
cloudinit/net/sysconfig.py.
[1]
https://git.launchpad.net/cloud-init/tree/cloudinit/sources/helpers/openstack.py#n587
[2] https://git.launchpad.net/cloud-init/tree/cloudinit/net/sysconfig.py#n346
** Affects: cloud-init
Importance: Undecided
Status: New
** Tags: rhel
--
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/1847517
Title:
cloudinit/net/sysconfig.py writed incorrect config for dhcp-stateless
openstack subnets
Status in cloud-init:
New
Bug description:
$ openstack subnet show 48c8407b-7ef3-4047-82dd-ca6d671c2162 -c
ipv6_address_mode -c ipv6_ra_mode
+---+--+
| Field | Value|
+---+--+
| ipv6_address_mode | dhcpv6-stateless |
| ipv6_ra_mode | dhcpv6-stateless |
+---+--+
File: openstack/latest/network_data.json
{
"services": [
{
"type": "dns",
"address": "fd12:3456:789a:1::1"
}
],
"networks": [
{
"network_id": "cf79eea0-6196-45a0-b9f8-ff9dd95eaab3",
"type": "ipv6_dhcpv6-stateless",
"services": [
{
"type": "dns",
"address": "fd12:3456:789a:1::1"
}
],
"netmask": ":::::",
"link": "tap5910c6cc-2d",
[Yahoo-eng-team] [Bug 1844124] Re: Not possible to change fixed-ips if port is on routed provider network
** Also affects: tripleo
Importance: Undecided
Status: New
** Changed in: tripleo
Importance: Undecided => High
** Changed in: tripleo
Status: New => Triaged
** Changed in: tripleo
Milestone: None => train-3
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1844124
Title:
Not possible to change fixed-ips if port is on routed provider network
Status in neutron:
New
Status in tripleo:
Triaged
Bug description:
For ports on normal networks (non-Routed Provider Networks) it is
possible to change the fixed-ip of a port. When a port is on a Routed
Provider Network the same operation return an error: "Invalid input
for operation: IP allocation requires subnets for network." Since this
is an unbound port, and the change does not move the port ip
allocation to a subnet associated with a different segment this
operation should succeed.
$ grep flat_networks /etc/neutron/plugins/ml2/ml2_conf.ini
flat_networks = public,mynetwork
$ openstack network create \
--provider-network-type flat \
--provider-physical-network mynetwork \
mynetwork
$ openstack subnet create \
--network mynetwork \
--network-segment $(openstack network segment list --network mynetwork -f
value -c ID) \
--subnet-range 192.168.254.0/24 \
--allocation-pool start=192.168.254.10,end=192.168.254.100 \
mysubnet
$ openstack network show mynetwork -f value -c id && openstack subnet show
mysubnet -f value -c id
57e622a0-3003-4d9f-b01e-c12613935265
df2cbb56-12b9-4156-8a23-36023b110b75
$ curl -s -X POST \
-H "X-Auth-Token: $(openstack token issue -f value -c id)" \
http://192.168.122.222:9696/v2.0/ports \
-d '{"port": {"name": "test-port", "network_id":
"57e622a0-3003-4d9f-b01e-c12613935265", "fixed_ips": [{"subnet_id":
"df2cbb56-12b9-4156-8a23-36023b110b75"}]}}' \
| python -m json.tool
{
"port": {
"admin_state_up": true,
"allowed_address_pairs": [],
"binding:host_id": "",
"binding:profile": {},
"binding:vif_details": {},
"binding:vif_type": "unbound",
"binding:vnic_type": "normal",
"created_at": "2019-09-16T11:56:06Z",
"description": "",
"device_id": "",
"device_owner": "",
"dns_assignment": [
{
"fqdn": "host-192-168-254-44.openstackgate.local.",
"hostname": "host-192-168-254-44",
"ip_address": "192.168.254.44"
}
],
"dns_domain": "",
"dns_name": "",
"extra_dhcp_opts": [],
"fixed_ips": [
{
"ip_address": "192.168.254.44",
"subnet_id": "df2cbb56-12b9-4156-8a23-36023b110b75"
}
],
"id": "84ef332d-8c48-422a-b400-0655702b1a0e",
"ip_allocation": "immediate",
"mac_address": "fa:16:3e:43:7c:fe",
"name": "test-port",
"network_id": "57e622a0-3003-4d9f-b01e-c12613935265",
"port_security_enabled": true,
"project_id": "4abf7cb77b574734adf086dfa828cd84",
"propagate_uplink_status": false,
"qos_policy_id": null,
"resource_request": null,
"revision_number": 1,
"security_groups": [
"708b5fa0-244c-46ee-9b35-30ba45a71ccf"
],
"status": "DOWN",
"tags": [],
"tenant_id": "4abf7cb77b574734adf086dfa828cd84",
"updated_at": "2019-09-16T11:56:06Z"
}
}
$ curl -s -X PUT \
-H "X-Auth-Token: $(openstack token issue -f value -c id)" \
http://192.168.122.222:9696/v2.0/ports/84ef332d-8c48-422a-b400-0655702b1a0e \
-d '{"port": {"fixed_ips": [{"ip_address": "192.168.254.100"}]}}' \
| python -m json.tool
{
"NeutronError": {
"detail": "",
"message": "Invalid input for operation: IP allocation requires
subnets for network.",
"type": "InvalidInput"
}
}
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1844124/+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 1844124] [NEW] Not possible to change fixed-ips if port is on routed provider network
Public bug reported:
For ports on normal networks (non-Routed Provider Networks) it is
possible to change the fixed-ip of a port. When a port is on a Routed
Provider Network the same operation return an error: "Invalid input for
operation: IP allocation requires subnets for network." Since this is an
unbound port, and the change does not move the port ip allocation to a
subnet associated with a different segment this operation should
succeed.
$ grep flat_networks /etc/neutron/plugins/ml2/ml2_conf.ini
flat_networks = public,mynetwork
$ openstack network create \
--provider-network-type flat \
--provider-physical-network mynetwork \
mynetwork
$ openstack subnet create \
--network mynetwork \
--network-segment $(openstack network segment list --network mynetwork -f
value -c ID) \
--subnet-range 192.168.254.0/24 \
--allocation-pool start=192.168.254.10,end=192.168.254.100 \
mysubnet
$ openstack network show mynetwork -f value -c id && openstack subnet show
mysubnet -f value -c id
57e622a0-3003-4d9f-b01e-c12613935265
df2cbb56-12b9-4156-8a23-36023b110b75
$ curl -s -X POST \
-H "X-Auth-Token: $(openstack token issue -f value -c id)" \
http://192.168.122.222:9696/v2.0/ports \
-d '{"port": {"name": "test-port", "network_id":
"57e622a0-3003-4d9f-b01e-c12613935265", "fixed_ips": [{"subnet_id":
"df2cbb56-12b9-4156-8a23-36023b110b75"}]}}' \
| python -m json.tool
{
"port": {
"admin_state_up": true,
"allowed_address_pairs": [],
"binding:host_id": "",
"binding:profile": {},
"binding:vif_details": {},
"binding:vif_type": "unbound",
"binding:vnic_type": "normal",
"created_at": "2019-09-16T11:56:06Z",
"description": "",
"device_id": "",
"device_owner": "",
"dns_assignment": [
{
"fqdn": "host-192-168-254-44.openstackgate.local.",
"hostname": "host-192-168-254-44",
"ip_address": "192.168.254.44"
}
],
"dns_domain": "",
"dns_name": "",
"extra_dhcp_opts": [],
"fixed_ips": [
{
"ip_address": "192.168.254.44",
"subnet_id": "df2cbb56-12b9-4156-8a23-36023b110b75"
}
],
"id": "84ef332d-8c48-422a-b400-0655702b1a0e",
"ip_allocation": "immediate",
"mac_address": "fa:16:3e:43:7c:fe",
"name": "test-port",
"network_id": "57e622a0-3003-4d9f-b01e-c12613935265",
"port_security_enabled": true,
"project_id": "4abf7cb77b574734adf086dfa828cd84",
"propagate_uplink_status": false,
"qos_policy_id": null,
"resource_request": null,
"revision_number": 1,
"security_groups": [
"708b5fa0-244c-46ee-9b35-30ba45a71ccf"
],
"status": "DOWN",
"tags": [],
"tenant_id": "4abf7cb77b574734adf086dfa828cd84",
"updated_at": "2019-09-16T11:56:06Z"
}
}
$ curl -s -X PUT \
-H "X-Auth-Token: $(openstack token issue -f value -c id)" \
http://192.168.122.222:9696/v2.0/ports/84ef332d-8c48-422a-b400-0655702b1a0e \
-d '{"port": {"fixed_ips": [{"ip_address": "192.168.254.100"}]}}' \
| python -m json.tool
{
"NeutronError": {
"detail": "",
"message": "Invalid input for operation: IP allocation requires subnets
for network.",
"type": "InvalidInput"
}
}
** 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/1844124
Title:
Not possible to change fixed-ips if port is on routed provider network
Status in neutron:
New
Bug description:
For ports on normal networks (non-Routed Provider Networks) it is
possible to change the fixed-ip of a port. When a port is on a Routed
Provider Network the same operation return an error: "Invalid input
for operation: IP allocation requires subnets for network." Since this
is an unbound port, and the change does not move the port ip
allocation to a subnet associated with a different segment this
operation should succeed.
$ grep flat_networks /etc/neutron/plugins/ml2/ml2_conf.ini
flat_networks = public,mynetwork
$ openstack network create \
--provider-network-type flat \
--provider-physical-network mynetwork \
mynetwork
$ openstack subnet create \
--network mynetwork \
--network-segment $(openstack network segment list --network mynetwork -f
value -c ID) \
--subnet-range 192.168.254.0/24 \
--allocation-pool start=192.168.254.10,end=192.168.254.100 \
mysubnet
$ openstack network show mynetwork -f value -c id && openstack subnet show
mysubnet -f value -c id
57e622a0-3003-4d9f-b01e-c12613935265
df2cbb56-12b9-4156-8a23-36023b110b75
$ curl -s -X POST \
-H "X-Auth-Token: $(openstack token issue -f value -c id
[Yahoo-eng-team] [Bug 1831811] [NEW] Unable to filter using same cidr value as used for subnet create
Public bug reported:
When subnets are created using a cidr the value provided is
normalized/converted to a proper subnet
https://opendev.org/openstack/neutron/src/branch/master/neutron/db/db_base_plugin_v2.py#L818-L820
818# turn the CIDR into a proper subnet
819net = netaddr.IPNetwork(s['cidr'])
820subnet['subnet']['cidr'] = '%s/%s' % (net.network, net.prefixlen)
I.e if the user create using `192.168.100.1/24` as the cidr the subnet create
is successfull. The cidr is turned into the proper subnet `192.168.100.0/24`
internally in the pre-commit.
When listing subnets and filtering using the same value for the cidr the return
is an empty list. Example:
$ curl -s -H "X-Auth-Token: $(openstack token issue -c id -f value)" -H
"Content-Type: application/json"
http://192.168.122.103:9696/v2.0/subnets?cidr=192.168.100.1/24 | json_reformat
{
"subnets": [
]
}
A user should be able to find the subnet by filtering using the same
`192.168.100.1/24` value used when creating the subnet.
** Affects: neutron
Importance: Undecided
Status: New
** Tags: queens-backport-potential
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1831811
Title:
Unable to filter using same cidr value as used for subnet create
Status in neutron:
New
Bug description:
When subnets are created using a cidr the value provided is
normalized/converted to a proper subnet
https://opendev.org/openstack/neutron/src/branch/master/neutron/db/db_base_plugin_v2.py#L818-L820
818# turn the CIDR into a proper subnet
819net = netaddr.IPNetwork(s['cidr'])
820subnet['subnet']['cidr'] = '%s/%s' % (net.network,
net.prefixlen)
I.e if the user create using `192.168.100.1/24` as the cidr the subnet create
is successfull. The cidr is turned into the proper subnet `192.168.100.0/24`
internally in the pre-commit.
When listing subnets and filtering using the same value for the cidr the
return is an empty list. Example:
$ curl -s -H "X-Auth-Token: $(openstack token issue -c id -f value)" -H
"Content-Type: application/json"
http://192.168.122.103:9696/v2.0/subnets?cidr=192.168.100.1/24 | json_reformat
{
"subnets": [
]
}
A user should be able to find the subnet by filtering using the same
`192.168.100.1/24` value used when creating the subnet.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1831811/+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 1828367] [NEW] Ironic notifier - Notify Ironic on port status changes
Public bug reported: More details in: https://storyboard.openstack.org/#!/story/1304673 Similar to how Nova can be notified (neutron/notifiers/nova.py) Ironic should also be notified on relevant port status changes. ** 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/1828367 Title: Ironic notifier - Notify Ironic on port status changes Status in neutron: New Bug description: More details in: https://storyboard.openstack.org/#!/story/1304673 Similar to how Nova can be notified (neutron/notifiers/nova.py) Ironic should also be notified on relevant port status changes. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1828367/+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 1823633] [NEW] [RFE] L3 - netfilter Contrack Helper Support
Public bug reported: OS distributions started to disable the nf_conntrack_helper functionality by default. (Ubuntu Bionic) Without the nf_conntrack_helper traffic such as tftp and other protocols that require a nf_conntrack module will not work. (This became apparent with Openstack Ironic which uses tftp transfer boot images during Pre Boot Execution (PXE) stopped working.) Desactivate the automatic conntrack helper assignment i better securitu practice, ref: https://github.com/regit/secure-conntrack-helpers/blob/master/secure-conntrack-helpers.rst This RFE is for adding support in Neutron to configure protocol specific CT target rules. This was discussed in meeting[1] 2019-03-20 with consensus on adding an L3 extension. [1] http://eavesdrop.openstack.org/irclogs/%23openstack-meeting/%23openstack-meeting.2019-03-20.log.html#t2019-03-20T14:47:08 ** Affects: neutron Importance: Undecided Status: New ** Tags: rfe -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1823633 Title: [RFE] L3 - netfilter Contrack Helper Support Status in neutron: New Bug description: OS distributions started to disable the nf_conntrack_helper functionality by default. (Ubuntu Bionic) Without the nf_conntrack_helper traffic such as tftp and other protocols that require a nf_conntrack module will not work. (This became apparent with Openstack Ironic which uses tftp transfer boot images during Pre Boot Execution (PXE) stopped working.) Desactivate the automatic conntrack helper assignment i better securitu practice, ref: https://github.com/regit/secure-conntrack-helpers/blob/master/secure-conntrack-helpers.rst This RFE is for adding support in Neutron to configure protocol specific CT target rules. This was discussed in meeting[1] 2019-03-20 with consensus on adding an L3 extension. [1] http://eavesdrop.openstack.org/irclogs/%23openstack-meeting/%23openstack-meeting.2019-03-20.log.html#t2019-03-20T14:47:08 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1823633/+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 1822100] [NEW] Networ Update if current provider net attribure key/value pair in request
Public bug reported:
Network initially created with:
{'network': {'provider:physical_network': 'external',
'provider:network_type': 'flat'}
Network is then updated with:
{'network': {'provider:physical_network': 'external',
'provider:network_type': 'flat',
'mtu': 9000}
The net_data is checked for provider attribute's being updated[1], this raises
the exception despite the actual values of provider net attributes did not
change.
[1]
https://github.com/openstack/neutron/blob/af130e79cbe5d12b7c9f9f4dcbcdc8d972bfcfd4/neutron/plugins/ml2/plugin.py#L988
** 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/1822100
Title:
Networ Update if current provider net attribure key/value pair in
request
Status in neutron:
New
Bug description:
Network initially created with:
{'network': {'provider:physical_network': 'external',
'provider:network_type': 'flat'}
Network is then updated with:
{'network': {'provider:physical_network': 'external',
'provider:network_type': 'flat',
'mtu': 9000}
The net_data is checked for provider attribute's being updated[1], this
raises the exception despite the actual values of provider net attributes did
not change.
[1]
https://github.com/openstack/neutron/blob/af130e79cbe5d12b7c9f9f4dcbcdc8d972bfcfd4/neutron/plugins/ml2/plugin.py#L988
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1822100/+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 1811905] [NEW] Deffered IP allocation, port update with binding_host_id + set new mac address fails
Public bug reported:
On a routed provider network IP allocation will be deffered if
insufficent binding information is available.
When a port is updated with binding_host_id only this works as expected:
$ openstack port create --network ctlplane testport -f yaml
admin_state_up: UP
allowed_address_pairs: ''
binding_host_id: ''
binding_profile: ''
binding_vif_details: ''
binding_vif_type: unbound
binding_vnic_type: normal
created_at: '2019-01-16T00:13:19Z'
data_plane_status: null
description: ''
device_id: ''
device_owner: ''
dns_assignment: null
dns_domain: null
dns_name: null
extra_dhcp_opts: ''
fixed_ips: ''
id: 9e05e8fe-c11a-4682-ba69-2a402094758d
mac_address: fa:16:3e:31:de:01
name: testport
network_id: 1f731773-6dcf-45ce-aa11-aaf205f2faf6
port_security_enabled: true
project_id: 9d8aea1921f04207b35a9e1fc4923ae1
qos_policy_id: null
revision_number: 1
security_group_ids: 2354cbbe-5726-42ef-8b45-e642cb9bf2ea
status: DOWN
tags: ''
trunk_details: null
updated_at: '2019-01-16T00:13:19Z'
$ openstack port set --host 05a94a66-27ca-4642-ad62-8f53827055c7
testport
$ openstack port show testport -f yaml
admin_state_up: UP
allowed_address_pairs: ''
binding_host_id: 05a94a66-27ca-4642-ad62-8f53827055c7
binding_profile: ''
binding_vif_details: ''
binding_vif_type: binding_failed
binding_vnic_type: normal
created_at: '2019-01-16T00:13:19Z'
data_plane_status: null
description: ''
device_id: ''
device_owner: ''
dns_assignment: null
dns_domain: null
dns_name: null
extra_dhcp_opts: ''
fixed_ips: ip_address='172.20.0.11',
subnet_id='61745187-973c-4515-a025-c719776bbf44'
id: 9e05e8fe-c11a-4682-ba69-2a402094758d
mac_address: fa:16:3e:31:de:01
name: testport
network_id: 1f731773-6dcf-45ce-aa11-aaf205f2faf6
port_security_enabled: true
project_id: 9d8aea1921f04207b35a9e1fc4923ae1
qos_policy_id: null
revision_number: 3
security_group_ids: 2354cbbe-5726-42ef-8b45-e642cb9bf2ea
status: DOWN
tags: ''
trunk_details: null
updated_at: '2019-01-16T00:13:58Z'
2019-01-16 01:13:58.064 38 DEBUG neutron.api.v2.base
[req-3baa886c-f409-4a2f-82b4-a46055e6653b 944d2af27c0e4e41bc8203acf9b4e6fb
9d8aea1921f04207b35a9e1fc4923ae1 - default default] Request body: {u'port':
{u'binding:host_id':
u'05a94a66-27ca-4642-ad62-8f53827055c7'}} prepare_request_body
/usr/lib/python2.7/site-packages/neutron/api/v2/base.py:715
2019-01-16 01:13:58.310 38 DEBUG neutron.db.db_base_plugin_common
[req-3baa886c-f409-4a2f-82b4-a46055e6653b 944d2af27c0e4e41bc8203acf9b4e6fb
9d8aea1921f04207b35a9e1fc4923ae1 - default default] Allocated IP 172.20.0.11
(1f731
773-6dcf-45ce-aa11-aaf205f2faf6/61745187-973c-4515-a025-c719776bbf44/9e05e8fe-c11a-4682-ba69-2a402094758d)
_store_ip_allocation
/usr/lib/python2.7/site-packages/neutron/db/db_base_plugin_common.py:124
When a port update request contain both binding_host_id and a new mac address,
IP allocation does not happen:
--
$ openstack port create --network ctlplane testport -f yaml
admin_state_up: UP
allowed_address_pairs: ''
binding_host_id: ''
binding_profile: ''
binding_vif_details: ''
binding_vif_type: unbound
binding_vnic_type: normal
created_at: '2019-01-16T00:15:35Z'
data_plane_status: null
description: ''
device_id: ''
device_owner: ''
dns_assignment: null
dns_domain: null
dns_name: null
extra_dhcp_opts: ''
fixed_ips: ''
id: 3c6ecca2-3f77-4528-86c2-66971c89ef2e
mac_address: fa:16:3e:aa:f4:46
name: testport
network_id: 1f731773-6dcf-45ce-aa11-aaf205f2faf6
port_security_enabled: true
project_id: 9d8aea1921f04207b35a9e1fc4923ae1
qos_policy_id: null
revision_number: 1
security_group_ids: 2354cbbe-5726-42ef-8b45-e642cb9bf2ea
status: DOWN
tags: ''
trunk_details: null
updated_at: '2019-01-16T00:15:35Z'
$ openstack port set --host 05a94a66-27ca-4642-ad62-8f53827055c7 --mac-
address 52:54:00:76:4f:56 testport
$ openstack port show testport -f yaml
admin_state_up: UP
allowed_address_pairs: ''
binding_host_id: 05a94a66-27ca-4642-ad62-8f53827055c7
binding_profile: ''
binding_vif_details: ''
binding_vif_type: binding_failed
binding_vnic_type: normal
created_at: '2019-01-16T00:15:35Z'
data_plane_status: null
description: ''
device_id: ''
device_owner: ''
dns_assignment: null
dns_domain: null
dns_name: null
extra_dhcp_opts: ''
fixed_ips: ''
id: 3c6ecca2-3f77-4528-86c2-66971c89ef2e
mac_address: 52:54:00:76:4f:56
name: testport
network_id: 1f731773-6dcf-45ce-aa11-aaf205f2faf6
port_security_enabled: true
project_id: 9d8aea1921f04207b35a9e1fc4923ae1
qos_policy_id: null
revision_number: 3
security_group_ids: 2354cbbe-5726-42ef-8b45-e642cb9bf2ea
status: DOWN
tags: ''
trunk_details: null
updated_at: '2019-01-16T00:15:46Z'
2019-01-16 01:15:45.684 39 DEBUG neutron.api.v2.base
[req-8373dd06-d3fe-4fdc-841e-3850ec6eb374 944d2af27c0e4e41bc8203acf9b4e6fb
9d8aea1921f04207b35a9e1fc4923ae1 - default default] Request body: {u'port':
{u'binding:host_id':
u'05a94a66-27ca-4642-ad62-8f53827055c7', u'mac_address':
u'52:54:00:76:4f:5
[Yahoo-eng-team] [Bug 1793391] [NEW] Subnet update with the subnet's current segment_id fail with: NoUpdateSubnetWhenMultipleSegmentsOnNetwork
Public bug reported:
When the update request contains segment_id and the provided segment_id
is equal to the id currently on the subnet, the update request will fail
if any of the checks in _validate_segment fail with
NoUpdateSubnetWhenMultipleSegmentsOnNetwork or
SubnetsNotAllAssociatedWithSegments.
[stack@heat-devstack ~]$ openstack network segment list --network testnet
+--+--+--+--+-+
| ID | Name | Network
| Network Type | Segment |
+--+--+--+--+-+
| 14ec1077-7836-45ec-9ce1-1bc45c670321 | net1 |
51394a06-75ce-401b-b46b-ebb2b34688b5 | flat | None|
| 884c98bb-22eb-4006-872b-966344d5bf8f | net2 |
51394a06-75ce-401b-b46b-ebb2b34688b5 | flat | None|
+--+--+--+--+-+
[stack@heat-devstack ~]$ openstack subnet list --network testnet
+--+-+--+-+
| ID | Name| Network
| Subnet |
+--+-+--+-+
| f21edda9-519e-4003-94f1-855c44a52cf8 | subnet1 |
51394a06-75ce-401b-b46b-ebb2b34688b5 | 10.100.100.0/24 |
+--+-+--+-+
[stack@heat-devstack ~]$ openstack subnet show subnet1
+---+--+
| Field | Value|
+---+--+
| allocation_pools | 10.100.100.2-10.100.100.254 |
| cidr | 10.100.100.0/24 |
| created_at| 2018-09-19T20:37:13Z |
| description | |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip| 10.100.100.1 |
| host_routes | |
| id| f21edda9-519e-4003-94f1-855c44a52cf8 |
| ip_version| 4|
| ipv6_address_mode | None |
| ipv6_ra_mode | None |
| name | subnet1 |
| network_id| 51394a06-75ce-401b-b46b-ebb2b34688b5 |
| project_id| fee5807fd59146bc973f89ce2a7c70bd |
| revision_number | 2|
| segment_id| 14ec1077-7836-45ec-9ce1-1bc45c670321 |
| service_types | |
| subnetpool_id | None |
| tags | |
| updated_at| 2018-09-19T20:40:54Z |
+---+--+
Actual result:
--
[stack@heat-devstack ~]$ curl -g -i -X PUT
http://192.168.122.222:9696/v2.0/subnets/f21edda9-519e-4003-94f1-855c44a52cf8
-H "Content-Type: application/json" -H "X-Auth-Token: $(openstack token issue
-f value -c id)" -d '{"subnet": {"segment_id":
"14ec1077-7836-45ec-9ce1-1bc45c670321"}}'
HTTP/1.1 400 Bad Request
Content-Type: application/json
Content-Length: 277
X-Openstack-Request-Id: req-999a512f-f49d-407a-bc8c-a7b9f3cb38a7
Date: Wed, 19 Sep 2018 20:43:27 GMT
{"NeutronError": {"message": "The network '51394a06-75ce-401b-b46b-
ebb2b34688b5' has multiple segments, it is only possible to associate an
existing subnet with a segment on networks with a single segment.",
"type": "NoUpdateSubnetWhenMultipleSegmentsOnNetwork", "detail": ""}}
Expected result:
[stack@heat-devstack ~]$ curl -g -i -X PUT
http://192.168.122.222:9696/v2.0/subnets/f21edda9-519e-4003-94f1-855c44a52cf8
-H "Content-Type: application/json" -H "X-Auth-Token: $(openstack token issue
-f value -c id)" -d '{"subnet": {"segment_id":
"14ec1077-7836-45ec-9ce1-1bc45c670321"}}'
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 670
X-Openstack-Request-Id: req-66f4d422-5a9d-4276-9eae-81142cff4aba
Date: Wed, 19 Sep 2018 21:07:08 GMT
{"subnet":{"updated_at":"2018-09-19T21:07:08Z","ipv6_ra_mode":null,"allocation_pools":[{"start":"10.100.100.2","end":"10.100.100.254"}],"host_routes":[],"revision_number":4,"ipv6_address_mode":null,"id":"f21edda9-519e-4003-94f1-855c44a52cf8","dns_nameservers":[],"gateway_ip":"10.100.100.1","project_id":"fee5807fd59146bc973f89ce2a7c70bd","description":"","tags":[],"cidr":"10.100.100.0/24","subnetpool_id":null,"service_types":[],"name":"subnet1","enable_dhcp":true,"segment_
[Yahoo-eng-team] [Bug 1694120] Re: routed-networks - segments subnet dhcp port bind to wrong segment
** Changed in: neutron
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1694120
Title:
routed-networks - segments subnet dhcp port bind to wrong segment
Status in neutron:
Invalid
Bug description:
$ openstack network list -f json
[]
$ openstack network create ctlplane
Network created, and we have 1 default segment:
$ openstack network segment list --network ctlplane -f json
[
{
"Network": "89e4aa6c-06f2-4348-9576-bec17c7526d6",
"Network Type": "local",
"Segment": null,
"ID": "46950790-717b-4d31-883a-a8d9d3df2e92",
"Name": null
}
]
$ openstack network segment create subnet0 --physical-network
ctlplane --network ctlplane --network-type flat
$ openstack subnet create --subnet-range 172.20.0.0/26 --dhcp
--gateway 172.20.0.62 --ip-version 4 --network ctlplane --network-
segment subnet0 --allocation-pool start=172.20.0.10,end=172.20.0.19
subnet0
(undercloud) [stack@ocataleafs ~]$ sudo ip netns list
qdhcp-89e4aa6c-06f2-4348-9576-bec17c7526d6
(undercloud) [stack@ocataleafs ~]$ sudo ip netns exec
qdhcp-89e4aa6c-06f2-4348-9576-bec17c7526d6 ip addr show | grep tap
13: tap0170296c-f2: mtu 1500 qdisc noqueue
state UNKNOWN qlen 1000
inet 172.20.0.10/26 brd 172.20.0.63 scope global tap0170296c-f2
(undercloud) [stack@ocataleafs ~]$ sudo ip netns exec
qdhcp-89e4aa6c-06f2-4348-9576-bec17c7526d6 ping 172.20.0.62
PING 172.20.0.62 (172.20.0.62) 56(84) bytes of data.
From 172.20.0.10 icmp_seq=1 Destination Host Unreachable
From 172.20.0.10 icmp_seq=2 Destination Host Unreachable
$ openstack network segment list -f json
[
{
"Network": "89e4aa6c-06f2-4348-9576-bec17c7526d6",
"Network Type": "local",
"Segment": null,
"ID": "46950790-717b-4d31-883a-a8d9d3df2e92",
"Name": null
},
{
"Network": "89e4aa6c-06f2-4348-9576-bec17c7526d6",
"Network Type": "flat",
"Segment": null,
"ID": "32a308e9-6f2e-4252-a273-95c7bfbcc94e",
"Name": "subnet0"
}
]
(undercloud) [stack@ocataleafs ~]$ openstack network segment delete
46950790-717b-4d31-883a-a8d9d3df2e92
Failed to delete network segment with ID
'46950790-717b-4d31-883a-a8d9d3df2e92': HttpException: Conflict (HTTP 409)
(Request-ID: req-8b1a5179-c987-47ba-b35a-68c9afdca4bc), Segment
'46950790-717b-4d31-883a-a8d9d3df2e92' cannot be deleted: The segment is still
bound with port(s) 0170296c-f2e5-4482-843a-3ebb0bf11381.
1 of 1 network segments failed to delete.
The dhcp-namespace port did not bind to the segment associated with
subnet0, it bound to the default segment that is automatically created
when creating a network.
If I change the workflow to first delete the default segment, and then
create segment: subnet0 + subnet: subnet0 the dhcp namespace is wired
correctly.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1694120/+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 1768690] [NEW] [RFE] Regenerate mac address of a port
Public bug reported: Openstack Ironic need to set the mac address of neutron port to the actual mac address of the hardware for DHCP/PXE deployment to work. When using pre-created neutron ports there is an issue where previously used ports cause a conflict when a new instance is scheduled onto the same baremetal hosts. Example: openstack port create --network private test-port1 openstack port create --network private test-port2 openstack server create \ --image cirros-0.3.5-x86_64-disk \ --port test-port1\ --flavor baremetal \ test-server openstack server delete test-server openstack server create \ --image cirros-0.3.5-x86_64-disk \ --port test-port2 \ --flavor baremetal \ test-server The second server create command fails with: fault: code: 500 created: '2018-04-29T12:21:37Z' < .. snip .. > message: 'Build of instance 5982f29a-3d48-4eb8-88ca-cf794c8f31dd aborted: Failure prepping block device.' An in conductor log: Apr 29 14:21:35 ironic-devstack.lab.example.com ironic-conductor[445]: ERROR ironic.common.neutron MacAddressInUseClient: Unable to complete operation for network 52497681-18f4-47de-b48e-1265799caea9. The mac address 52:54:00:53:b5:b9 is in use. It should be possible to "return" the port by resetting a mac in the base MAC address Neutron uses for VIFs. e.g a port update request that triggers regeneration of the mac address. Ironic would add this to it's interface detach method, to ensure no previously used ports cause issues when deploying new baremetal instances. ** Affects: neutron Importance: Undecided Status: New ** Tags: rfe -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1768690 Title: [RFE] Regenerate mac address of a port Status in neutron: New Bug description: Openstack Ironic need to set the mac address of neutron port to the actual mac address of the hardware for DHCP/PXE deployment to work. When using pre-created neutron ports there is an issue where previously used ports cause a conflict when a new instance is scheduled onto the same baremetal hosts. Example: openstack port create --network private test-port1 openstack port create --network private test-port2 openstack server create \ --image cirros-0.3.5-x86_64-disk \ --port test-port1\ --flavor baremetal \ test-server openstack server delete test-server openstack server create \ --image cirros-0.3.5-x86_64-disk \ --port test-port2 \ --flavor baremetal \ test-server The second server create command fails with: fault: code: 500 created: '2018-04-29T12:21:37Z' < .. snip .. > message: 'Build of instance 5982f29a-3d48-4eb8-88ca-cf794c8f31dd aborted: Failure prepping block device.' An in conductor log: Apr 29 14:21:35 ironic-devstack.lab.example.com ironic-conductor[445]: ERROR ironic.common.neutron MacAddressInUseClient: Unable to complete operation for network 52497681-18f4-47de-b48e-1265799caea9. The mac address 52:54:00:53:b5:b9 is in use. It should be possible to "return" the port by resetting a mac in the base MAC address Neutron uses for VIFs. e.g a port update request that triggers regeneration of the mac address. Ironic would add this to it's interface detach method, to ensure no previously used ports cause issues when deploying new baremetal instances. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1768690/+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 1766380] [NEW] [RFE] Create host-routes for routed networks (segments)
Public bug reported: When using routed networks[1] on an instance connected to multiple networks the traffic from a segmant_a to segment_b within a L3 network might be routed via a different network if the default router/gateway is not on the interface connecting to the routed networks. It would be good to (at-least have an option to) automatically configure host_routes on the subnets in a routed L3 network. In such a way that traffic with a destination on a different segment within the same L3 network is routed via the instance interface connecting to the L3 network. Example: instance_a: - port_a: some_net, segmentA, subnet0 <-- default gateway - port_b: net1, segmentA, subnet0 instance_b: - port_a: other_net, segmentA, subnet0 <-- default gateway - port_a: net1, segmentB, subnet0 Unless a host-route is in place, traffic from instance_a to instance_b will use some/other-net, not net1 which both is connected to. This RFE is to have the host_routes property on the subnets withing net1 populated, so that clients are aware of neighbour L3 networks. [1] https://docs.openstack.org/neutron/latest/admin/config-routed- networks.html ** Affects: neutron Importance: Undecided Status: New ** Tags: rfe ** Description changed: When using routed networks[1] on an instance connected to multiple networks the traffic from a segmant_a to segment_b within a L3 network might be routed via a different network if the default router/gateway is not on the interface connecting to the routed networks. It would be good to (at-least have an option to) automatically configure host_routes on the subnets in a routed L3 network. In such a way that traffic with a destination on a different segment within the same L3 network is routed via the instance interface connecting to the L3 network. Example: - instance_a: -- port_a: some_net, segmentA, subnet0 <-- The default gateway via this interface. -- port_b: net1, segmentA, subnet0 + instance_a: + - port_a: some_net, segmentA, subnet0 <-- default gateway + - port_b: net1, segmentA, subnet0 - instance_b: -- port_a: other_net, segmentA, subnet0 <-- The default gateway via this interface. -- port_a: net1, segmentB, subnet0 + instance_b: + - port_a: other_net, segmentA, subnet0 <-- default gateway + - port_a: net1, segmentB, subnet0 Unless a host-route is in place to use a routed on net1 is in place, traffic from instance_a to instance_b will use some/other-net, not net1 which both is connected to. This RFE is to have the host_routes property on the subnets withing net1 populated, so that clients are aware of neighbour L3 networks. [1] https://docs.openstack.org/neutron/latest/admin/config-routed- networks.html ** Description changed: When using routed networks[1] on an instance connected to multiple networks the traffic from a segmant_a to segment_b within a L3 network might be routed via a different network if the default router/gateway is not on the interface connecting to the routed networks. It would be good to (at-least have an option to) automatically configure host_routes on the subnets in a routed L3 network. In such a way that traffic with a destination on a different segment within the same L3 network is routed via the instance interface connecting to the L3 network. Example: instance_a: - port_a: some_net, segmentA, subnet0 <-- default gateway - port_b: net1, segmentA, subnet0 instance_b: - port_a: other_net, segmentA, subnet0 <-- default gateway - port_a: net1, segmentB, subnet0 - Unless a host-route is in place to use a routed on net1 is in place, - traffic from instance_a to instance_b will use some/other-net, not net1 - which both is connected to. + Unless a host-route is in place, traffic from instance_a to instance_b + will use some/other-net, not net1 which both is connected to. This RFE is to have the host_routes property on the subnets withing net1 populated, so that clients are aware of neighbour L3 networks. [1] https://docs.openstack.org/neutron/latest/admin/config-routed- networks.html -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1766380 Title: [RFE] Create host-routes for routed networks (segments) Status in neutron: New Bug description: When using routed networks[1] on an instance connected to multiple networks the traffic from a segmant_a to segment_b within a L3 network might be routed via a different network if the default router/gateway is not on the interface connecting to the routed networks. It would be good to (at-least have an option to) automatically configure host_routes on the subnets in a routed L3 network. In such a way that traffic with a destination on a different segment within the same L3 network is routed via the
[Yahoo-eng-team] [Bug 1743579] [NEW] Concurrent report_state from multiple agents: segment_host_mapping fails - StaleDataError
Public bug reported:
When multiple host agents rapidly report_state for the first time we get
StaleDataError and _update_segment_host_mapping_for_agent does not
complete for all hosts.
Attached is a file with logs as well as reproducer script and
instruction on how to set up devstack environment similar to the one I
am using.
To Reproduce:
-
Run script with the delay, time.sleep(10), commented.
Results:
* 2x StaleDataError
* Only 1 attempt to add host to placement/host-aggregate.
MariaDB [neutron]> MariaDB [neutron]> SELECT * FROM segmenthostmappings;
+--+-+
| segment_id | host|
+--+-+
| a974ae4c-1389-4e41-9ab9-820165c26acd | host2 |
| a974ae4c-1389-4e41-9ab9-820165c26acd | routed-devstack.lab.example.com |
| bc626d3d-5503-4875-9db8-e1bcfad35979 | host2 |
| bc626d3d-5503-4875-9db8-e1bcfad35979 | routed-devstack.lab.example.com |
| ec7717dd-8533-464f-a3c8-4ecc7dc08d10 | host2 |
| ec7717dd-8533-464f-a3c8-4ecc7dc08d10 | routed-devstack.lab.example.com |
+--+-+
Conclutions:
* 2x StaleDataError
* 1x successfull _update_segment_host_mapping after_create.
*** We should see 3x attempts to add to placement/host-aggregate, one
for each host agent.
Running the reproducer script with the delay uncommented (No issue):
Run script with the delay, time.sleep(10), enabled.
Results:
* No StaleDataError
* 3 attempts to add the host to placemenb/host-aggregate.
MariaDB [neutron]> SELECT * FROM segmenthostmappings;
+--+-+
| segment_id | host|
+--+-+
| 11b9258f-8712-43b7-8f39-3eab627a8c7f | host0 |
| 11b9258f-8712-43b7-8f39-3eab627a8c7f | host1 |
| 11b9258f-8712-43b7-8f39-3eab627a8c7f | host2 |
| 11b9258f-8712-43b7-8f39-3eab627a8c7f | routed-devstack.lab.example.com |
| 89f96bee-424c-4ee2-8639-2ca8e07a70e6 | host0 |
| 89f96bee-424c-4ee2-8639-2ca8e07a70e6 | host1 |
| 89f96bee-424c-4ee2-8639-2ca8e07a70e6 | host2 |
| 89f96bee-424c-4ee2-8639-2ca8e07a70e6 | routed-devstack.lab.example.com |
| a7a7d2f4-c809-4ebb-916f-930c97fbec47 | host0 |
| a7a7d2f4-c809-4ebb-916f-930c97fbec47 | host1 |
| a7a7d2f4-c809-4ebb-916f-930c97fbec47 | host2 |
| a7a7d2f4-c809-4ebb-916f-930c97fbec47 | routed-devstack.lab.example.com |
+--+-+
Conclution:
* 3x successfull _update_segment_host_mapping after_create.
** NOTE: **
The RESP BODY: {"itemNotFound": {"message": "Compute host host1 could not be
found.", "code": 404}} errors in the logs is expected, the fake host is not in
Nova, so this is expeced.
** Affects: neutron
Importance: Undecided
Status: New
** Attachment added: "Logs, a reproducer script and devstack instructions."
https://bugs.launchpad.net/bugs/1743579/+attachment/5037862/+files/reproducer_and_logs.txt
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1743579
Title:
Concurrent report_state from multiple agents: segment_host_mapping
fails - StaleDataError
Status in neutron:
New
Bug description:
When multiple host agents rapidly report_state for the first time we
get StaleDataError and _update_segment_host_mapping_for_agent does not
complete for all hosts.
Attached is a file with logs as well as reproducer script and
instruction on how to set up devstack environment similar to the one I
am using.
To Reproduce:
-
Run script with the delay, time.sleep(10), commented.
Results:
* 2x StaleDataError
* Only 1 attempt to add host to placement/host-aggregate.
MariaDB [neutron]> MariaDB [neutron]> SELECT * FROM segmenthostmappings;
+--+-+
| segment_id | host|
+--+-+
| a974ae4c-1389-4e41-9ab9-820165c26acd | host2 |
| a974ae4c-1389-4e41-9ab9-820165c26acd | routed-devstack.lab.example.com |
| bc626d3d-5503-4875-9db8-e1bcfad35979 | host2 |
| bc626d3d-5503-4875-9db8-e1bcfad35979 | routed-devstac
[Yahoo-eng-team] [Bug 1736220] [NEW] TypeError: __init__() got an unexpected keyword argument 'topics'
Public bug reported: FakeNotifier class 'topic' argument need to be updated to 'topics'. The Notifyer class in oslo.messaging was changed in Change-Id: Id89957411aa219cff92fafec2f448c81cb57b3ca ** 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/1736220 Title: TypeError: __init__() got an unexpected keyword argument 'topics' Status in neutron: New Bug description: FakeNotifier class 'topic' argument need to be updated to 'topics'. The Notifyer class in oslo.messaging was changed in Change-Id: Id89957411aa219cff92fafec2f448c81cb57b3ca To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1736220/+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 1692567] Re: can't create neutron port fixed_ip if subnet associated with segment
Hi Rico Lin,
The following change in Neutron was released:
https://review.openstack.org/#/c/470788/
With this we can close both the Heat and Neutron part of this bug.
--
Harald
** Changed in: neutron
Status: New => Fix Released
** Changed in: heat
Status: Incomplete => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1692567
Title:
can't create neutron port fixed_ip if subnet associated with segment
Status in heat:
Fix Released
Status in neutron:
Fix Released
Bug description:
There doesn't seem to be a way to create a fixed_ip for an
OS::Neutron::Port if the subnet is associated with a Neutron segment.
For example, using this:
resources:
instance_port:
type: OS::Neutron::Port
properties:
network: ctlplane
fixed_ips: [{"subnet": ctlplane-subnet0, "ip_address": 10.8.146.8}]
my_ironic_instance:
type: OS::Nova::Server
properties:
key_name: default
image: overcloud-full
flavor: baremetal
networks:
- network: ctlplane
port: {get_resource: instance_port}
If the subnet is NOT associated with a segment, I am able to create a
stack with a Neutron port with 10.8.146.8 as expected.
However, in this case the subnet is associated with a neutron segment:
[stack@host01 ~]$ neutron subnet-show ctlplane-subnet0
+---++
| Field | Value
|
+---++
| allocation_pools | {"start": "10.8.146.5", "end": "10.8.146.20"}
|
| cidr | 10.8.146.0/24
|
| created_at| 2017-05-19T21:57:53Z
|
| description |
|
| dns_nameservers |
|
| enable_dhcp | True
|
| gateway_ip| 10.8.146.1
|
| host_routes | {"destination": "169.254.169.254/32", "nexthop":
"10.8.146.1"} |
| id| 2510cb92-e3f7-4ef3-98a8-ba409c33406b
|
| ip_version| 4
|
| ipv6_address_mode |
|
| ipv6_ra_mode |
|
| name | ctlplane-subnet0
|
| network_id| 5f93540c-b00e-42c7-b1a1-0560906d9a8d
|
| project_id| 08b43a05b88c4d4089355b3aba9dd8fb
|
| revision_number | 2
|
| segment_id| d5b2dc5d-ee11-4057-9481-fd28fab14b31
|
| service_types |
|
| subnetpool_id |
|
| tags |
|
| tenant_id | 08b43a05b88c4d4089355b3aba9dd8fb
|
| updated_at| 2017-05-19T21:57:53Z
|
+---++
[stack@host01 ~]$ openstack network segment show
d5b2dc5d-ee11-4057-9481-fd28fab14b31
+--+--+
| Field| Value|
+--+--+
| description | None |
| id | d5b2dc5d-ee11-4057-9481-fd28fab14b31 |
| name | subnet0 |
| network_id | 5f93540c-b00e-42c7-b1a1-0560906d9a8d |
| network_type | flat |
| physical_network | ctlplane |
| segmentation_id | None |
+--+--+
The stack is created successfuly, however the neutron port has a fixed_ip
from the allocation_pool (10.8.146.15, see below) not the defined fixed_ip in
the template.
[stack@host01 ~]$ heat stack-list
+--++-+--+--+
| id | stack_name | stack_status|
creat
[Yahoo-eng-team] [Bug 1699754] [NEW] [RFE] DHCP linux agent - set in dhcp-range option to support networks via ralay agent
Public bug reported: To complete the DHCP support for remote routed networks via relay agent the dhcp agent must configure the in the --dhcp-range option. This was previously not requred becuase dnsmasq can determine it from the local interface information. For remote networks we need to set this property. DNSMASQ(8) """ For directly connected networks (ie, networks on which the machine running dnsmasq has an interface) the netmask is optional: dnsmasq will determine it from the interface configuration. For networks which receive DHCP service via a relay agent, dnsmasq cannot determine the netmask itself, so it should be specified, otherwise dnsmasq will have to guess, based on the class (A, B or C) of the network address. The broadcast address is always optional. It is always allowed to have more than one dhcp-range in a single subnet. """ ** Affects: neutron Importance: Undecided Status: New ** Tags: l3-ipam-dhcp -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1699754 Title: [RFE] DHCP linux agent - set in dhcp-range option to support networks via ralay agent Status in neutron: New Bug description: To complete the DHCP support for remote routed networks via relay agent the dhcp agent must configure the in the --dhcp- range option. This was previously not requred becuase dnsmasq can determine it from the local interface information. For remote networks we need to set this property. DNSMASQ(8) """ For directly connected networks (ie, networks on which the machine running dnsmasq has an interface) the netmask is optional: dnsmasq will determine it from the interface configuration. For networks which receive DHCP service via a relay agent, dnsmasq cannot determine the netmask itself, so it should be specified, otherwise dnsmasq will have to guess, based on the class (A, B or C) of the network address. The broadcast address is always optional. It is always allowed to have more than one dhcp-range in a single subnet. """ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1699754/+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 1695740] [NEW] Segments, routed-networks, IPAM only usecase regression
Public bug reported: Segments, routed-networks, IPAM only usecase regression Code[1] will defer IP allocation if host is not specified. Issues: a) This breaks the use case where Neutron is used for IPAM only with routed network. b) A user can no longer create a port and specify a fixed IP, then later bind the port without loosing the fixed-ip information. Issue b) above is a very common pattern in Heat templates. It is used in Heat templates examples, ref: - https://github.com/openstack/heat-templates/blob/master/hot/servers_in_new_neutron_net.yaml#L77:L82 - https://github.com/openstack/heat-templates/blob/master/hot/servers_in_existing_neutron_net.yaml#L30:L46 Current behaviour with segments is that ip-allocation is deferred for _any_ port create. Deferring ip allocation if the host is not known does make sense. Before host is known the available segments are also not known and we need to wait until the scheduler has picked a host and nova adds binding:host_id. However... ... this does not make sense if the subnet or fixed-ip is specified in the port create request. In this case we should not defer allocation, the user specified exactly what they want and it is known where to allocate the IP. When / If this port is later bound to a host, an error will be raised if that host does not have the correct segments. This is essentially the same update scenario already covered in the code?[2] When creating an instance using an existing port with and IP address, the scheduler should take the ip-allocation data from the port provided in the request and ensure that the instance is scheduled to a host that is connected to the correct segment. According to nova neutron-routed- networks spec[1] this exact use case was included. """ Use case 2: User has a port that has an IP address and thus is effectively attached to a segment (but not bound to a host). He/She provides it to nova boot. Nova will ask Neutron for the segment to which the port is bound by getting the details of the port. Given that segment, the scheduler should place the instance on a compute host belonging to the corresponding aggregate. """ [1] https://github.com/openstack/neutron/blob/master/neutron/db/ipam_backend_mixin.py#L662:L700 [2] https://github.com/openstack/neutron/blob/master/neutron/db/ipam_backend_mixin.py#L769:L777 [3] https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/neutron-routed-networks.html ** Affects: neutron Importance: Undecided Status: New ** Tags: l3-ipam-dhcp ** Description changed: Segments, routed-networks, IPAM only usecase regression Code[1] will defer IP allocation if host is not specified. - Issues: - a) This breaks the use case where Neutron is used for IPAM only with routed network. - b) A user can no longer create a port and specify a fixed IP, then later bind the - port without loosing the fixed-ip information. + Issues: + a) This breaks the use case where Neutron is used for IPAM only with + routed network. + b) A user can no longer create a port and specify a fixed IP, then later + bind the port without loosing the fixed-ip information. - Issue b) above is a very common pattern in Heat templates. It is used in Heat templates examples, ref: - - https://github.com/openstack/heat-templates/blob/master/hot/servers_in_new_neutron_net.yaml#L77:L82 - - https://github.com/openstack/heat-templates/blob/master/hot/servers_in_existing_neutron_net.yaml#L30:L46 + Issue b) above is a very common pattern in Heat templates. + It is used in Heat templates examples, ref: + - https://github.com/openstack/heat-templates/blob/master/hot/servers_in_new_neutron_net.yaml#L77:L82 + - https://github.com/openstack/heat-templates/blob/master/hot/servers_in_existing_neutron_net.yaml#L30:L46 Current behaviour with segments is that ip-allocation is deferred for _any_ port create. Deferring ip allocation if the host is not known does make sense. Before host is known the available segments are also not known and we need to wait until the scheduler has picked a host and nova adds binding:host_id. However... ... this does not make sense if the subnet or fixed-ip is specified in the port create request. In this case we should not defer allocation, the user specified exactly what they want and it is known where to allocate the IP. When / If this port is later bound to a host, an error will be raised if that host does not have the correct segments. This is essentially the same update scenario already covered in the code?[2] When creating an instance using an existing port with and IP address, the scheduler should take the ip-allocation data from the port provided in the request and ensure that the instance is scheduled to a host that is connected to the correct segment. According to nova neutron-routed- networks spec[1] this exact us
[Yahoo-eng-team] [Bug 1694120] [NEW] routed-networks - segments subnet dhcp port bind to wrong segment
Public bug reported:
$ openstack network list -f json
[]
$ openstack network create ctlplane
Network created, and we have 1 default segment:
$ openstack network segment list --network ctlplane -f json
[
{
"Network": "89e4aa6c-06f2-4348-9576-bec17c7526d6",
"Network Type": "local",
"Segment": null,
"ID": "46950790-717b-4d31-883a-a8d9d3df2e92",
"Name": null
}
]
$ openstack network segment create subnet0 --physical-network ctlplane
--network ctlplane --network-type flat
$ openstack subnet create --subnet-range 172.20.0.0/26 --dhcp --gateway
172.20.0.62 --ip-version 4 --network ctlplane --network-segment subnet0
--allocation-pool start=172.20.0.10,end=172.20.0.19 subnet0
(undercloud) [stack@ocataleafs ~]$ sudo ip netns list
qdhcp-89e4aa6c-06f2-4348-9576-bec17c7526d6
(undercloud) [stack@ocataleafs ~]$ sudo ip netns exec
qdhcp-89e4aa6c-06f2-4348-9576-bec17c7526d6 ip addr show | grep tap
13: tap0170296c-f2: mtu 1500 qdisc noqueue
state UNKNOWN qlen 1000
inet 172.20.0.10/26 brd 172.20.0.63 scope global tap0170296c-f2
(undercloud) [stack@ocataleafs ~]$ sudo ip netns exec
qdhcp-89e4aa6c-06f2-4348-9576-bec17c7526d6 ping 172.20.0.62
PING 172.20.0.62 (172.20.0.62) 56(84) bytes of data.
>From 172.20.0.10 icmp_seq=1 Destination Host Unreachable
>From 172.20.0.10 icmp_seq=2 Destination Host Unreachable
$ openstack network segment list -f json
[
{
"Network": "89e4aa6c-06f2-4348-9576-bec17c7526d6",
"Network Type": "local",
"Segment": null,
"ID": "46950790-717b-4d31-883a-a8d9d3df2e92",
"Name": null
},
{
"Network": "89e4aa6c-06f2-4348-9576-bec17c7526d6",
"Network Type": "flat",
"Segment": null,
"ID": "32a308e9-6f2e-4252-a273-95c7bfbcc94e",
"Name": "subnet0"
}
]
(undercloud) [stack@ocataleafs ~]$ openstack network segment delete
46950790-717b-4d31-883a-a8d9d3df2e92
Failed to delete network segment with ID
'46950790-717b-4d31-883a-a8d9d3df2e92': HttpException: Conflict (HTTP 409)
(Request-ID: req-8b1a5179-c987-47ba-b35a-68c9afdca4bc), Segment
'46950790-717b-4d31-883a-a8d9d3df2e92' cannot be deleted: The segment is still
bound with port(s) 0170296c-f2e5-4482-843a-3ebb0bf11381.
1 of 1 network segments failed to delete.
The dhcp-namespace port did not bind to the segment associated with
subnet0, it bound to the default segment that is automatically created
when creating a network.
If I change the workflow to first delete the default segment, and then
create segment: subnet0 + subnet: subnet0 the dhcp namespace is wired
correctly.
** Affects: neutron
Importance: Undecided
Status: New
** Tags: l3-ipam-dhcp
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1694120
Title:
routed-networks - segments subnet dhcp port bind to wrong segment
Status in neutron:
New
Bug description:
$ openstack network list -f json
[]
$ openstack network create ctlplane
Network created, and we have 1 default segment:
$ openstack network segment list --network ctlplane -f json
[
{
"Network": "89e4aa6c-06f2-4348-9576-bec17c7526d6",
"Network Type": "local",
"Segment": null,
"ID": "46950790-717b-4d31-883a-a8d9d3df2e92",
"Name": null
}
]
$ openstack network segment create subnet0 --physical-network
ctlplane --network ctlplane --network-type flat
$ openstack subnet create --subnet-range 172.20.0.0/26 --dhcp
--gateway 172.20.0.62 --ip-version 4 --network ctlplane --network-
segment subnet0 --allocation-pool start=172.20.0.10,end=172.20.0.19
subnet0
(undercloud) [stack@ocataleafs ~]$ sudo ip netns list
qdhcp-89e4aa6c-06f2-4348-9576-bec17c7526d6
(undercloud) [stack@ocataleafs ~]$ sudo ip netns exec
qdhcp-89e4aa6c-06f2-4348-9576-bec17c7526d6 ip addr show | grep tap
13: tap0170296c-f2: mtu 1500 qdisc noqueue
state UNKNOWN qlen 1000
inet 172.20.0.10/26 brd 172.20.0.63 scope global tap0170296c-f2
(undercloud) [stack@ocataleafs ~]$ sudo ip netns exec
qdhcp-89e4aa6c-06f2-4348-9576-bec17c7526d6 ping 172.20.0.62
PING 172.20.0.62 (172.20.0.62) 56(84) bytes of data.
From 172.20.0.10 icmp_seq=1 Destination Host Unreachable
From 172.20.0.10 icmp_seq=2 Destination Host Unreachable
$ openstack network segment list -f json
[
{
"Network": "89e4aa6c-06f2-4348-9576-bec17c7526d6",
"Network Type": "local",
"Segment": null,
"ID": "46950790-717b-4d31-883a-a8d9d3df2e92",
"Name": null
},
{
"Network": "89e4aa6c-06f2-4348-9576-bec17c7526d6",
"Network Type": "flat",
"Segment": null,
"ID": "32a308e9-6f2e-4252-a273-95c7bfbcc94e",
"Name": "subnet0"
}
]
(undercloud) [stack@ocataleafs ~]$ openstack network segment delete
46950790-717b-4d31-883a-a8d9d3df2e92
Failed to delete network segment with ID
'46950790-717b-4d31-883a-a8d9d3df2e92': HttpException: Conflict (HT
[Yahoo-eng-team] [Bug 1693284] Re: Routed Networks - Ironic Port Binding - baremetal node on remote non-local subnet
** Summary changed: - Unable to create port with fixed-ips allocation for 'baremetal' ironic instance + Routed Networks - Ironic Port Binding - baremetal node on remote non-local subnet ** Description changed: When using routed networks and a subnet is associated with a segment ip- allocation will be deferred unless binding:host_id is provided. This is all fine for ports that will end up on a nova host, we want to make sure the ip-allocation is for a subnet on a segment that is local to the target host. - For the Ironic, baremtal, usecase this is however an issue since the - port will not actually bind to any host. With the current implementation - I think the only way to make this work would require a seperate Ironic - node in each network segment. + For the Ironic, baremtal, usecase the 'host_id' used for port binding is the node running the Ironic services. + https://github.com/openstack/ironic/blob/master/ironic/drivers/modules/network/flat.py#L64 + + + This would require a separate ironic node in each segment of a routed network? e.g one per rack in a spine-and-leaf datacenter? ** Also affects: ironic 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/1693284 Title: Routed Networks - Ironic Port Binding - baremetal node on remote non- local subnet Status in Ironic: New Status in neutron: In Progress Bug description: When using routed networks and a subnet is associated with a segment ip-allocation will be deferred unless binding:host_id is provided. This is all fine for ports that will end up on a nova host, we want to make sure the ip-allocation is for a subnet on a segment that is local to the target host. For the Ironic, baremtal, usecase the 'host_id' used for port binding is the node running the Ironic services. https://github.com/openstack/ironic/blob/master/ironic/drivers/modules/network/flat.py#L64 This would require a separate ironic node in each segment of a routed network? e.g one per rack in a spine-and-leaf datacenter? To manage notifications about this bug go to: https://bugs.launchpad.net/ironic/+bug/1693284/+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 1693284] [NEW] Unable to create port with fixed-ips allocation for 'baremetal' ironic instance
Public bug reported: When using routed networks and a subnet is associated with a segment ip- allocation will be deferred unless binding:host_id is provided. This is all fine for ports that will end up on a nova host, we want to make sure the ip-allocation is for a subnet on a segment that is local to the target host. For the Ironic, baremtal, usecase this is however an issue since the port will not actually bind to any host. With the current implementation I think the only way to make this work would require a seperate Ironic node in each network segment. ** Affects: neutron Importance: Undecided Status: New ** Tags: l3-ipam-dhcp -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1693284 Title: Unable to create port with fixed-ips allocation for 'baremetal' ironic instance Status in neutron: New Bug description: When using routed networks and a subnet is associated with a segment ip-allocation will be deferred unless binding:host_id is provided. This is all fine for ports that will end up on a nova host, we want to make sure the ip-allocation is for a subnet on a segment that is local to the target host. For the Ironic, baremtal, usecase this is however an issue since the port will not actually bind to any host. With the current implementation I think the only way to make this work would require a seperate Ironic node in each network segment. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1693284/+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 1692490] [NEW] [RFE] Ability to migrate a non-Segment subnet to a Segment
Public bug reported: With Neutron segments it is not possible to mix subnets with segment_id: None and subnets with a segment_id. In some cases a network will be created, a subnet added without creating a segment. tTen later this network need to scale, and dividing it onto multiple routed segments is required. To be able to support migration from non-routed, to a routed network we would like the ability to migrate current subnets on a network with no segments to a segment. The migration can/should be limited to migrating the subnet to a segment that use the same "provider:physical_network". This feature woulb enable possibility to upgrade/migrate existing Triplo deployments to neutron routed segments model. ** Affects: neutron Importance: Undecided Status: New ** Tags: rfe -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1692490 Title: [RFE] Ability to migrate a non-Segment subnet to a Segment Status in neutron: New Bug description: With Neutron segments it is not possible to mix subnets with segment_id: None and subnets with a segment_id. In some cases a network will be created, a subnet added without creating a segment. tTen later this network need to scale, and dividing it onto multiple routed segments is required. To be able to support migration from non-routed, to a routed network we would like the ability to migrate current subnets on a network with no segments to a segment. The migration can/should be limited to migrating the subnet to a segment that use the same "provider:physical_network". This feature woulb enable possibility to upgrade/migrate existing Triplo deployments to neutron routed segments model. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1692490/+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 1692486] [NEW] [RFE] Neutron Segments DHCP-relay support
Public bug reported: When using Neutron Segments we would like dhcp agent to configure DHCP servers to serve clients on remote(non-local) subnets. The remote(non- local) subnet will need to have a DHCP-relay/forwarder configured. The relay agent will run on ToR switch or router in the routed underlay network and would be configured by the operator, it does not need to be managed by neutron. Currently the Neutron Segments implementation expect a DHCP agent to be available on all segments, and thus non-local subnets are filtered in dhcp_rpc to return only subnets local to the agent. To support DHCP relay we need to return all subnets and inform the DHCP agent wich subnets are local vs non-local so that the DHCP agent will only bind port/ip-address to the subnets that is local. Implementation of the dhpc_rpc part of this has been started with these reviews: https://review.openstack.org/#/c/459861/ https://review.openstack.org/#/c/438171/ https://review.openstack.org/#/c/462209 The discussion in comment 10 of this bug 1668145 is relevant: https://bugs.launchpad.net/neutron/+bug/1668145/comments/10 ** Affects: neutron Importance: Undecided Status: In Progress ** Tags: l3-ipam-dhcp ** Changed in: neutron Status: New => 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/1692486 Title: [RFE] Neutron Segments DHCP-relay support Status in neutron: In Progress Bug description: When using Neutron Segments we would like dhcp agent to configure DHCP servers to serve clients on remote(non-local) subnets. The remote(non- local) subnet will need to have a DHCP-relay/forwarder configured. The relay agent will run on ToR switch or router in the routed underlay network and would be configured by the operator, it does not need to be managed by neutron. Currently the Neutron Segments implementation expect a DHCP agent to be available on all segments, and thus non-local subnets are filtered in dhcp_rpc to return only subnets local to the agent. To support DHCP relay we need to return all subnets and inform the DHCP agent wich subnets are local vs non-local so that the DHCP agent will only bind port/ip-address to the subnets that is local. Implementation of the dhpc_rpc part of this has been started with these reviews: https://review.openstack.org/#/c/459861/ https://review.openstack.org/#/c/438171/ https://review.openstack.org/#/c/462209 The discussion in comment 10 of this bug 1668145 is relevant: https://bugs.launchpad.net/neutron/+bug/1668145/comments/10 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1692486/+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 1691047] [NEW] dhcp agent - multiple interfaces, last iface coming up overwrite resolv.conf
Public bug reported: The resolv.conf gets populated with whatever the last interface that came up over DHCP provided. Even if the 2nd network/subnet in neutron doesn’t define DNS, it still overwrites resolv.conf. By default the dnsmasq agent will use itself, and it's pairs as DNS servers if no dns_servers are provided for the neutron subnet. Ref: https://github.com/openstack/neutron/blob/master/neutron/agent/linux/dhcp.py#L877:L887 https://github.com/openstack/neutron/blob/master/neutron/agent/linux/dhcp.py#L970 This is not always desired. Is there a way to disable this behaviour, and simply not offer any dns servers if there are none specified in the neutron subnet? ** 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/1691047 Title: dhcp agent - multiple interfaces, last iface coming up overwrite resolv.conf Status in neutron: New Bug description: The resolv.conf gets populated with whatever the last interface that came up over DHCP provided. Even if the 2nd network/subnet in neutron doesn’t define DNS, it still overwrites resolv.conf. By default the dnsmasq agent will use itself, and it's pairs as DNS servers if no dns_servers are provided for the neutron subnet. Ref: https://github.com/openstack/neutron/blob/master/neutron/agent/linux/dhcp.py#L877:L887 https://github.com/openstack/neutron/blob/master/neutron/agent/linux/dhcp.py#L970 This is not always desired. Is there a way to disable this behaviour, and simply not offer any dns servers if there are none specified in the neutron subnet? To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1691047/+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 1685152] [NEW] [RFE] SR-IOV - HotPlug support
Public bug reported: The Nova interface-attach API needs be enhanced to support SR-IOV. There is a Newton blueprint for this: https://review.openstack.org/#/c/139910/ It has been abandoned, and need to be picked up for ocata/pike. ** 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/1685152 Title: [RFE] SR-IOV - HotPlug support Status in OpenStack Compute (nova): New Bug description: The Nova interface-attach API needs be enhanced to support SR-IOV. There is a Newton blueprint for this: https://review.openstack.org/#/c/139910/ It has been abandoned, and need to be picked up for ocata/pike. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1685152/+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 1669594] [NEW] DHCP host_routes should be Neutron Segment aware
Public bug reported: The following code in neutron/agent/linux/dhcp.py will create on-link /link-local routes to all subnets in a network. host_routes.extend(["%s,0.0.0.0" % (s.cidr) for s in self.network.subnets if (s.ip_version == 4 and s.cidr != subnet.cidr)]) White the introduction of Neutron segments, this needs to be update so that host_routes for on-link destinations are only created if l2-adjacency is True. We should also create host_routes for all subnets whithin the same segment, as I understand it l2-adjacency is guaranteed within each segment. And Segment can have multiple Subnets. ref: http://specs.openstack.org/openstack/neutron-specs/specs/newton/routed-networks.html ** 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/1669594 Title: DHCP host_routes should be Neutron Segment aware Status in neutron: New Bug description: The following code in neutron/agent/linux/dhcp.py will create on-link /link-local routes to all subnets in a network. host_routes.extend(["%s,0.0.0.0" % (s.cidr) for s in self.network.subnets if (s.ip_version == 4 and s.cidr != subnet.cidr)]) White the introduction of Neutron segments, this needs to be update so that host_routes for on-link destinations are only created if l2-adjacency is True. We should also create host_routes for all subnets whithin the same segment, as I understand it l2-adjacency is guaranteed within each segment. And Segment can have multiple Subnets. ref: http://specs.openstack.org/openstack/neutron-specs/specs/newton/routed-networks.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1669594/+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 1668145] [NEW] Allow the end user control of "on-link" routes for subnets in the same Neutron network
Public bug reported:
When adding multiple subnets on a single network the dhcp agent will set
dhcp-options to advertise "on-link"/"same-segment" classless static
routes to all the subnets.
A couple of use cases where these on-link/link-local routes are
undesirable:
a) When using Ironic for baremetal provisioning the baremetal nodes
might be on a different L2 broadcast segment with a DHCP-relay.
b) In a Spine-Leaf deployed Openstack, a pattern is to use identical
VLAN id's for provider networks in each leaf. Same VLAN id, but
different L2 domain and different IP subnets.
IMO, creating these routes are a bit opinionated. If we don't create them by
default, the operator/end-user is fully able to create them if they are desired
on a per-subnet basis. But since we decided these "should" be there, the
operator loose the ability to control this.
** Affects: neutron
Importance: Undecided
Assignee: Harald Jensås (harald-jensas)
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/1668145
Title:
Allow the end user control of "on-link" routes for subnets in the same
Neutron network
Status in neutron:
In Progress
Bug description:
When adding multiple subnets on a single network the dhcp agent will
set dhcp-options to advertise "on-link"/"same-segment" classless
static routes to all the subnets.
A couple of use cases where these on-link/link-local routes are
undesirable:
a) When using Ironic for baremetal provisioning the baremetal nodes
might be on a different L2 broadcast segment with a DHCP-relay.
b) In a Spine-Leaf deployed Openstack, a pattern is to use identical
VLAN id's for provider networks in each leaf. Same VLAN id, but
different L2 domain and different IP subnets.
IMO, creating these routes are a bit opinionated. If we don't create them by
default, the operator/end-user is fully able to create them if they are desired
on a per-subnet basis. But since we decided these "should" be there, the
operator loose the ability to control this.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1668145/+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 1590310] [NEW] Reduce excessive LBaaSv2 logging
Public bug reported: Description of problem: When a tenant creates a v2 HAProxy load balancer without a listener, minimally $ neutron lbaas-loadbalancer-create below kind of messages are then logged on every 10 seconds in lbaas- agent.log for each such load balancer of any tenant: 2016-04-07 17:34:18.763 25200 WARNING neutron_lbaas.drivers.haproxy.namespace_driver [-] Stats socket not found for loadbalancer c86c8dd7-74a1-435f-ad60-f47d2006cb06 At minimum, the level and frequency of these messages should be adjusted. ** Affects: neutron Importance: Undecided Status: New ** Tags: lbaas -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1590310 Title: Reduce excessive LBaaSv2 logging Status in neutron: New Bug description: Description of problem: When a tenant creates a v2 HAProxy load balancer without a listener, minimally $ neutron lbaas-loadbalancer-create below kind of messages are then logged on every 10 seconds in lbaas- agent.log for each such load balancer of any tenant: 2016-04-07 17:34:18.763 25200 WARNING neutron_lbaas.drivers.haproxy.namespace_driver [-] Stats socket not found for loadbalancer c86c8dd7-74a1-435f-ad60-f47d2006cb06 At minimum, the level and frequency of these messages should be adjusted. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1590310/+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
