[Yahoo-eng-team] [Bug 1439824] [NEW] Support multiple IPv6 prefixes on internal router ports
Public bug reported: Provide support for adding multiple IPv6 subnets to an internal router port. This was part of the multiple-ipv6-prefixes blueprint (https://blueprints.launchpad.net/neutron/+spec/multiple-ipv6-prefixes), but did not make it into Kilo and is instead being re-targeted for Liberty. ** Affects: neutron Importance: Undecided Assignee: Andrew Boik (drewboik) Status: In Progress ** Tags: ipv6 ** Changed in: neutron Assignee: (unassigned) => Andrew Boik (drewboik) ** 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/1439824 Title: Support multiple IPv6 prefixes on internal router ports Status in OpenStack Neutron (virtual network service): In Progress Bug description: Provide support for adding multiple IPv6 subnets to an internal router port. This was part of the multiple-ipv6-prefixes blueprint (https://blueprints.launchpad.net/neutron/+spec/multiple- ipv6-prefixes), but did not make it into Kilo and is instead being re- targeted for Liberty. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1439824/+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 1438819] [NEW] Validate number of addresses for router GW port
Public bug reported: We need to validate a router's gateway port during creation and update of a router gateway port by ensuring it has no more than one v4 fixed IP and one v6 fixed IP. There is currently no check for this. ** Affects: neutron Importance: Undecided Assignee: Andrew Boik (drewboik) Status: In Progress ** Changed in: neutron Assignee: (unassigned) => Andrew Boik (drewboik) ** 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/1438819 Title: Validate number of addresses for router GW port Status in OpenStack Neutron (virtual network service): In Progress Bug description: We need to validate a router's gateway port during creation and update of a router gateway port by ensuring it has no more than one v4 fixed IP and one v6 fixed IP. There is currently no check for this. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1438819/+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 1437855] [NEW] Floating IPs should be associated with the first fixed IPv4 address
Public bug reported: If a port attached to an instance has multiple fixed IPs and a floating IP is associated without specifying a fixed ip to associate, the behavior in Neutron is to reject the associate request. The behavior in Nova in the absence of a specified fixed ip, however, is to pick the first one from the list of fixed ips on the port. This is a problem if an IPv6 address is the first on the port because the floating IP will be NAT'ed to the IPv6 fixed address, which is not supported. Any attempts to reach the instance through its floating address will fail. This causes failures in certain scenario tests that use the Nova floating IP API when dual-stack IPv4+IPv6 is enabled, such as test_baremetal_basic_ops in check-tempest-dsvm-ironic-pxe_ssh in https://review.openstack.org/#/c/168063 ** Affects: nova Importance: Undecided Assignee: Andrew Boik (drewboik) Status: In Progress ** Tags: api network ** Changed in: nova Status: New => In Progress ** Changed in: nova Assignee: (unassigned) => Andrew Boik (drewboik) ** Description changed: If a port attached to an instance has multiple fixed IPs and a floating IP is associated without specifying a fixed ip to associate, the behavior in Neutron is to reject the associate request. The behavior in Nova in the absence of a specified fixed ip, however, is to pick the first one from the list of fixed ips on the port. This is a problem if an IPv6 address is the first on the port because the floating IP will be NAT'ed to the IPv6 fixed address, which is not - supported. Any attempts to reach the instance through it's floating + supported. Any attempts to reach the instance through its floating address will fail. This causes failures in certain scenario tests that use the Nova floating IP API when dual-stack IPv4+IPv6 is enabled, such as test-baremetal-basic-ops in check-tempest-dsvm-ironic-pxe_ssh in https://review.openstack.org/#/c/168063 ** Description changed: If a port attached to an instance has multiple fixed IPs and a floating IP is associated without specifying a fixed ip to associate, the behavior in Neutron is to reject the associate request. The behavior in Nova in the absence of a specified fixed ip, however, is to pick the first one from the list of fixed ips on the port. This is a problem if an IPv6 address is the first on the port because the floating IP will be NAT'ed to the IPv6 fixed address, which is not supported. Any attempts to reach the instance through its floating address will fail. This causes failures in certain scenario tests that use the Nova floating IP API when dual-stack IPv4+IPv6 is enabled, such - as test-baremetal-basic-ops in check-tempest-dsvm-ironic-pxe_ssh in + as test_baremetal_basic_ops in check-tempest-dsvm-ironic-pxe_ssh in https://review.openstack.org/#/c/168063 -- 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/1437855 Title: Floating IPs should be associated with the first fixed IPv4 address Status in OpenStack Compute (Nova): In Progress Bug description: If a port attached to an instance has multiple fixed IPs and a floating IP is associated without specifying a fixed ip to associate, the behavior in Neutron is to reject the associate request. The behavior in Nova in the absence of a specified fixed ip, however, is to pick the first one from the list of fixed ips on the port. This is a problem if an IPv6 address is the first on the port because the floating IP will be NAT'ed to the IPv6 fixed address, which is not supported. Any attempts to reach the instance through its floating address will fail. This causes failures in certain scenario tests that use the Nova floating IP API when dual-stack IPv4+IPv6 is enabled, such as test_baremetal_basic_ops in check-tempest-dsvm-ironic-pxe_ssh in https://review.openstack.org/#/c/168063 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1437855/+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 1437499] [NEW] init_l3 should consider all address scopes
Public bug reported: Currently init_l3 retrieves the list of global addresses from the kernel on a specific device in a network namespace. If any of the addresses are not in the ip_cidrs argument to init_l3, they will be deleted. The problem with only listing global addresses is that if a site-local or link-local address is added during a subnet-create, and the user wishes to later delete the address, init_l3 will never consider that address for deletion. To fix this, init_l3 should not limit its scope when listing addresses on an interface. It should, however, ignore the default IPv6 link-local address assigned by the operating system as this address is not known to Neutron and should not be deleted. ** Affects: neutron Importance: Undecided Assignee: Andrew Boik (drewboik) Status: New ** Tags: ipv6 ** Changed in: neutron Assignee: (unassigned) => Andrew Boik (drewboik) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1437499 Title: init_l3 should consider all address scopes Status in OpenStack Neutron (virtual network service): New Bug description: Currently init_l3 retrieves the list of global addresses from the kernel on a specific device in a network namespace. If any of the addresses are not in the ip_cidrs argument to init_l3, they will be deleted. The problem with only listing global addresses is that if a site-local or link-local address is added during a subnet-create, and the user wishes to later delete the address, init_l3 will never consider that address for deletion. To fix this, init_l3 should not limit its scope when listing addresses on an interface. It should, however, ignore the default IPv6 link- local address assigned by the operating system as this address is not known to Neutron and should not be deleted. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1437499/+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 1437496] [NEW] port-update --fixed-ips doesn't work for routers
Public bug reported: Performing a port-update with a different set of fixed-ips than are currently on the port will be reported as a success by Neutron, however the actual addresses will not be updated in the Linux network namespace. This now has more functional implications as a result of multiple subnets being allowed on the external router interface (https://review.openstack.org/#/c/149068). If the interface has two subnets and the user wishes to remove one, they will have to clear the gateway interface first, removing both (causing traffic disruption), delete the subnet, and re-set the gateway on the router to re-add the remaining subnet. If port-update were functional for router addresses, this command could be used to remove a second subnet without causing disruption to the first. ** Affects: neutron Importance: Undecided Assignee: Andrew Boik (drewboik) Status: New ** Tags: ipv6 ** Changed in: neutron Assignee: (unassigned) => Andrew Boik (drewboik) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1437496 Title: port-update --fixed-ips doesn't work for routers Status in OpenStack Neutron (virtual network service): New Bug description: Performing a port-update with a different set of fixed-ips than are currently on the port will be reported as a success by Neutron, however the actual addresses will not be updated in the Linux network namespace. This now has more functional implications as a result of multiple subnets being allowed on the external router interface (https://review.openstack.org/#/c/149068). If the interface has two subnets and the user wishes to remove one, they will have to clear the gateway interface first, removing both (causing traffic disruption), delete the subnet, and re-set the gateway on the router to re-add the remaining subnet. If port-update were functional for router addresses, this command could be used to remove a second subnet without causing disruption to the first. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1437496/+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 1424760] [NEW] SLAAC/DHCPv6-stateless subnets can be deleted with router ports still in-use
ubnet is deleted from the router port in Neutron. Subnet still exists in the
router namespace:
dboik@dboik-VirtualBox:/opt/stack/neutron/neutron$ sudo ip netns exec
qrouter-7950-cbad-487a-9b43-18f739bf492e ifconfig
loLink encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
qg-31640bf5-55 Link encap:Ethernet HWaddr fa:16:3e:96:41:b7
inet6 addr: fe80::f816:3eff:fe96:41b7/64 Scope:Link
inet6 addr: 2001:420:2c50:200a::1/64 Scope:Global
UP BROADCAST RUNNING MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:1134 (1.1 KB)
qr-e86154dd-fe Link encap:Ethernet HWaddr fa:16:3e:c3:5a:3e
inet6 addr: fe80::f816:3eff:fec3:5a3e/64 Scope:Link
inet6 addr: cafe::1/64 Scope:Global
UP BROADCAST RUNNING MTU:1500 Metric:1
RX packets:46 errors:0 dropped:0 overruns:0 frame:0
TX packets:13 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:5060 (5.0 KB) TX bytes:1294 (1.2 KB)
RADVD continues to advertise this prefix.
** Affects: neutron
Importance: Undecided
Assignee: Andrew Boik (drewboik)
Status: New
** Tags: ipv6 juno-backport-potential
** Changed in: neutron
Assignee: (unassigned) => Andrew Boik (drewboik)
** Description changed:
SLAAC and DHCPv6-stateless subnets can be deleted using the subnet-
delete command even when they still have associated internal router
ports. This causes the subnet to be deleted from the Neutron database,
yet in reality the subnet still exists with radvd continuing to
advertise the prefix to clients on the network. Calling subnet-delete on
a subnet that still has internal router ports should result in an error.
===
===
- === Steps to reproduce: ===
+ Steps to reproduce:
===
===
1. Create a slaac or dhcpv6-stateless subnet
dboik@dboik-VirtualBox:/opt/stack/neutron/neutron$ neutron subnet-create
--ip-version 6 --ipv6-ra-mode slaac --ipv6-address-mode slaac --name subv6
private cafe::/64
Created a new subnet:
+---+--+
| Field | Value
|
+---+--+
| allocation_pools | {"start": "cafe::2", "end":
"cafe:::::fffe"} |
| cidr | cafe::/64
|
| dns_nameservers |
|
| enable_dhcp | True
|
| gateway_ip| cafe::1
|
| host_routes |
|
| id| f878a81c-3fdf-46f1-9719-fdbdb314d822
|
| ip_version| 6
|
| ipv6_address_mode | slaac
|
| ipv6_ra_mode | slaac
|
| name | subv6
|
| network_id| 77b850fd-8f87-4001-aa2e-6375a87b9598
|
| tenant_id | dc748d64a2fc4ec798e9a16d5f6cb444
|
+---+--+
2. Create a router interface using this subnet
dboik@dboik-VirtualBox:/opt/stack/neutron/neutron$ neutron
router-interface-add router1 subv6
Added interface e86154dd-fee6-435d-8065-55cf4b2ae860 to router router1.
dboik@dboik-VirtualBox:/opt/stack/neutron/neutron$ neutron router-port-list
router1
+--+--+---+--+
| id | name | mac_address | fixed_ips
|
+--+--+---+-
[Yahoo-eng-team] [Bug 1392798] [NEW] Deleted instances show power state as 'Running'
Public bug reported: After deleting an instance and executing a `nova list --deleted` command as an administrator, the Power State of the deleted instance is still displayed as 'Running' and set to 1 in the database as well. Steps to reproduce: Boot an instance: dboik@dboik-VirtualBox:~$ nova boot foo --flavor m1.tiny --image cirros-032-x86_64-uec Wait for instance to finish building: dboik@dboik-VirtualBox:~$ nova list +--+--+++-+--+ | ID | Name | Status | Task State | Power State | Networks | +--+--+++-+--+ | 2fed0daa-b083-43cf-9285-7364ce4852ce | foo | ACTIVE | - | Running | private=10.0.0.2 | +--+--+++-+--+ Delete the instance: dboik@dboik-VirtualBox:~$ nova delete foo Request to delete server foo has been accepted. As an OpenStack administrator, list the deleted instances: dboik@dboik-VirtualBox:~$ nova list --deleted +--+--+-++-+--+ | ID | Name | Status | Task State | Power State | Networks | +--+--+-++-+--+ | 2fed0daa-b083-43cf-9285-7364ce4852ce | foo | DELETED | - | Running | private=10.0.0.2 | +--+--+-++-+--+ ** Affects: nova Importance: Undecided Assignee: Andrew Boik (drewboik) Status: In Progress ** Changed in: nova Assignee: (unassigned) => Andrew Boik (drewboik) -- 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/1392798 Title: Deleted instances show power state as 'Running' Status in OpenStack Compute (Nova): In Progress Bug description: After deleting an instance and executing a `nova list --deleted` command as an administrator, the Power State of the deleted instance is still displayed as 'Running' and set to 1 in the database as well. Steps to reproduce: Boot an instance: dboik@dboik-VirtualBox:~$ nova boot foo --flavor m1.tiny --image cirros-032-x86_64-uec Wait for instance to finish building: dboik@dboik-VirtualBox:~$ nova list +--+--+++-+--+ | ID | Name | Status | Task State | Power State | Networks | +--+--+++-+--+ | 2fed0daa-b083-43cf-9285-7364ce4852ce | foo | ACTIVE | - | Running | private=10.0.0.2 | +--+--+++-+--+ Delete the instance: dboik@dboik-VirtualBox:~$ nova delete foo Request to delete server foo has been accepted. As an OpenStack administrator, list the deleted instances: dboik@dboik-VirtualBox:~$ nova list --deleted +--+--+-++-+--+ | ID | Name | Status | Task State | Power State | Networks | +--+--+-++-+--+ | 2fed0daa-b083-43cf-9285-7364ce4852ce | foo | DELETED | - | Running | private=10.0.0.2 | +--+--+-++-+--+ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1392798/+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 1379811] [NEW] VPN: Update logging to use i18n hints
Public bug reported: The VPN logging code should use the new marker functions for info, warning, error and critical log levels to separate log messages into different catalogs for translation priority. We also need to ensure that the new i18n guidelines are followed. ** Affects: neutron Importance: Undecided Assignee: Andrew Boik (drewboik) Status: In Progress ** Tags: i18n vpnaas ** Changed in: neutron Assignee: (unassigned) => Andrew Boik (drewboik) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1379811 Title: VPN: Update logging to use i18n hints Status in OpenStack Neutron (virtual network service): In Progress Bug description: The VPN logging code should use the new marker functions for info, warning, error and critical log levels to separate log messages into different catalogs for translation priority. We also need to ensure that the new i18n guidelines are followed. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1379811/+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
