[Yahoo-eng-team] [Bug 1514068] [NEW] internal subnet case no need to repeatedly create IPDevice in _update_arp_entry
Public bug reported: _update_arp_entry will create IPDevice to do arp task: https://github.com/openstack/neutron/blob/master/neutron/agent/l3/dvr_local_router.py#L200-L227 def _update_arp_entry(self, ip, mac, subnet_id, operation): """Add or delete arp entry into router namespace for the subnet.""" port = self._get_internal_port(subnet_id) # update arp entry only if the subnet is attached to the router if not port: return False try: # TODO(mrsmith): optimize the calls below for bulk calls interface_name = self.get_internal_device_name(port['id']) device = ip_lib.IPDevice(interface_name, namespace=self.ns_name) and methods _process_arp_cache_for_internal_port and _set_subnet_arp_info will call _update_arp_entry in their for loop based on arp_entry/port. Per arp_entry/port is going to be processed, an IPDevice object(same device in namespace) will be created. It's not necessary to do that. https://github.com/openstack/neutron/blob/master/neutron/agent/l3/dvr_local_router.py#L174-L182 https://github.com/openstack/neutron/blob/master/neutron/agent/l3/dvr_local_router.py#L229-L241 We can create that IPDevice object before code enter the for loop, and pass it to _update_arp_entry ** Affects: neutron Importance: Undecided Assignee: ZongKai LI (lzklibj) Status: New ** Changed in: neutron Assignee: (unassigned) => ZongKai LI (lzklibj) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1514068 Title: internal subnet case no need to repeatedly create IPDevice in _update_arp_entry Status in neutron: New Bug description: _update_arp_entry will create IPDevice to do arp task: https://github.com/openstack/neutron/blob/master/neutron/agent/l3/dvr_local_router.py#L200-L227 def _update_arp_entry(self, ip, mac, subnet_id, operation): """Add or delete arp entry into router namespace for the subnet.""" port = self._get_internal_port(subnet_id) # update arp entry only if the subnet is attached to the router if not port: return False try: # TODO(mrsmith): optimize the calls below for bulk calls interface_name = self.get_internal_device_name(port['id']) device = ip_lib.IPDevice(interface_name, namespace=self.ns_name) and methods _process_arp_cache_for_internal_port and _set_subnet_arp_info will call _update_arp_entry in their for loop based on arp_entry/port. Per arp_entry/port is going to be processed, an IPDevice object(same device in namespace) will be created. It's not necessary to do that. https://github.com/openstack/neutron/blob/master/neutron/agent/l3/dvr_local_router.py#L174-L182 https://github.com/openstack/neutron/blob/master/neutron/agent/l3/dvr_local_router.py#L229-L241 We can create that IPDevice object before code enter the for loop, and pass it to _update_arp_entry To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1514068/+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 1514082] [NEW] network_data.json does not provide information about ipv6 addresses.
Public bug reported:
Environment:
centos 7
openstack liberty
# rpm -qa|grep nova
openstack-nova-api-12.0.0-1.el7.noarch
python-novaclient-2.30.1-1.el7.noarch
openstack-nova-novncproxy-12.0.0-1.el7.noarch
openstack-nova-conductor-12.0.0-1.el7.noarch
python-nova-12.0.0-1.el7.noarch
openstack-nova-console-12.0.0-1.el7.noarch
openstack-nova-common-12.0.0-1.el7.noarch
openstack-nova-compute-12.0.0-1.el7.noarch
openstack-nova-cert-12.0.0-1.el7.noarch
openstack-nova-scheduler-12.0.0-1.el7.noarch
Steps to reproduce:
1) Create network with ipv6 subnet.
# neutron net-list
+--+--+---+
| id | name | subnets
|
+--+--+---+
| 286b3e3c-9075-496f-8899-c9890397f087 | net2 |
de602f61-8e05-4337-bc9d-c9f8265bb937 1000:2000::/24 |
| a3931414-73c3-40c9-a39b-d93ae38844a2 | net3 |
b6ce48ab-9387-4128-baa3-4a893dd27bb7 10.0.2.0/24 |
| a5d1181f-bedd-40a5-8b4a-5574b74dba61 | net1 |
72be780a-6df9-47ea-991c-e6fa97396adc 192.168.122.0/24 |
+--+--+---+
2) Create instance with 3 nic
# nova boot \
--flavor 2 \
--image fedora23 \
--config-drive=True \
--nic net-id=a5d1181f-bedd-40a5-8b4a-5574b74dba61 \
--nic net-id=286b3e3c-9075-496f-8899-c9890397f087 \
--nic net-id=a3931414-73c3-40c9-a39b-d93ae38844a2 \
--user-data=/root/cloud-config \
test
# nova list
+--+--+++-+--+
| ID | Name | Status | Task State | Power
State | Networks |
+--+--+++-+--+
| 4f159a96-8154-4946-b2a3-50c2638f545b | test | ACTIVE | - | Running
| net3=10.0.2.116; net2=1000:2000:3000::1102; net1=192.168.122.117 |
+--+--+++-+--+
Logon to instance, mount configDrive:
# mount /dev/disk/by-label/config-2 /mnt/
Actual result:
# cat /mnt/openstack/latest/network_data.json | python3 -m json.tool
{
"links": [
{
"ethernet_mac_address": "fa:16:3e:db:48:10",
"id": "tap54d10236-5d",
"mtu": null,
"type": "ovs",
"vif_id": "54d10236-5d15-4e22-b584-2a185d74b553"
},
{
"ethernet_mac_address": "fa:16:3e:db:c2:96",
"id": "tapae9677cb-32",
"mtu": null,
"type": "ovs",
"vif_id": "ae9677cb-327b-4fc9-9b99-88ebd96595a3"
},
{
"ethernet_mac_address": "fa:16:3e:10:37:07",
"id": "tap1baef501-47",
"mtu": null,
"type": "ovs",
"vif_id": "1baef501-47b0-4c76-928f-34ed2827c7d4"
}
],
"networks": [
{
"id": "network0",
"link": "tap54d10236-5d",
"network_id": "a5d1181f-bedd-40a5-8b4a-5574b74dba61",
"type": "ipv4_dhcp"
},
{
"id": "network1",
"ip_address": "10.0.2.116",
"link": "tap1baef501-47",
"netmask": "255.255.255.0",
"network_id": "a3931414-73c3-40c9-a39b-d93ae38844a2",
"routes": [],
"type": "ipv4"
}
],
"services": []
}
network_data.json provide information about ipv4 adresses only.
Expected result:
network_data.json provide information about all ip adresses.
** Affects: nova
Importance: Undecided
Status: New
** Tags: metadata
--
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/1514082
Title:
network_data.json does not provide information about ipv6 addresses.
Status in OpenStack Compute (nova):
New
Bug description:
Environment:
centos 7
openstack liberty
# rpm -qa|grep nova
openstack-nova-api-12.0.0-1.el7.noarch
python-novaclient-2.30.1-1.el7.noarch
openstack-nova-novncproxy-12.0.0-1.el7.noarch
openstack-nova-conductor-12.0.0-1.el7.noarch
python-nova-12.0.0-1.el7.noarch
openstack-nova-console-12.0.0-1.el7.noarch
openstack-nova-common-12.0.0-1.el7.noarch
openstack-nova-compute-12.0.0-1.el7.noarch
openstack-nova-cert-12.0.0-1.el7.noarch
openstack-nova-scheduler-12.0.0-1.el7.noarch
Steps to reproduce:
1) Create network with ipv6 subnet.
# neutron net-list
[Yahoo-eng-team] [Bug 1323975] Re: do not use default=None for config options
** Also affects: magnum Importance: Undecided Status: New ** Changed in: magnum Assignee: (unassigned) => Hou Ming Wang (houming-wang) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1323975 Title: do not use default=None for config options Status in Barbican: Fix Released Status in Ceilometer: Fix Released Status in Cinder: In Progress Status in Glance: Fix Released Status in heat: Fix Released Status in Ironic: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in Magnum: New Status in neutron: Fix Released Status in OpenStack Compute (nova): Fix Released Status in oslo-incubator: Fix Released Status in oslo.messaging: Fix Released Status in Sahara: Fix Released Status in Trove: In Progress Status in zaqar: Fix Released Bug description: In the cfg module default=None is set as the default value. It's not necessary to set it again when defining config options. To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1323975/+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 1514056] [NEW] Set agent timestamp aka cookie to physical bridges
Public bug reported: Currently ovs agent only explicitly sets agent timestamp to br-int and br-tun bridges. Other physical bridges that are configured receive cookie=0x0 for their flows because the agent doesn't set timestamp for these bridges. Currently that doesn't lead to any malfunction, however it's better to provide a consistentsy over operations with bridges's flows. ** Affects: neutron Importance: Low Assignee: Eugene Nikanorov (enikanorov) 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/1514056 Title: Set agent timestamp aka cookie to physical bridges Status in neutron: New Bug description: Currently ovs agent only explicitly sets agent timestamp to br-int and br-tun bridges. Other physical bridges that are configured receive cookie=0x0 for their flows because the agent doesn't set timestamp for these bridges. Currently that doesn't lead to any malfunction, however it's better to provide a consistentsy over operations with bridges's flows. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1514056/+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 1514048] [NEW] The Networks tests file is very large/ bloated
Public bug reported: The networks tests files in Horizon contain tests for Ports, Subnets and Agents, although there is barely any interdependency aside from a couple of shared imports or strings. These resources should have their own tests files to avoid further bloating the networks file (currently well over 2000 lines) ** Affects: horizon Importance: Undecided Assignee: Rob Cresswell (robcresswell) Status: New ** Changed in: horizon Assignee: (unassigned) => Rob Cresswell (robcresswell) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1514048 Title: The Networks tests file is very large/ bloated Status in OpenStack Dashboard (Horizon): New Bug description: The networks tests files in Horizon contain tests for Ports, Subnets and Agents, although there is barely any interdependency aside from a couple of shared imports or strings. These resources should have their own tests files to avoid further bloating the networks file (currently well over 2000 lines) To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1514048/+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 1514082] Re: network_data.json does not provide information about ipv6 addresses.
Sorry, not a bug.
Fixed by configure nova.conf:
[DEFAULT]
use_ipv6=true
** Changed in: nova
Status: New => Invalid
--
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/1514082
Title:
network_data.json does not provide information about ipv6 addresses.
Status in OpenStack Compute (nova):
Invalid
Bug description:
Environment:
centos 7
openstack liberty
# rpm -qa|grep nova
openstack-nova-api-12.0.0-1.el7.noarch
python-novaclient-2.30.1-1.el7.noarch
openstack-nova-novncproxy-12.0.0-1.el7.noarch
openstack-nova-conductor-12.0.0-1.el7.noarch
python-nova-12.0.0-1.el7.noarch
openstack-nova-console-12.0.0-1.el7.noarch
openstack-nova-common-12.0.0-1.el7.noarch
openstack-nova-compute-12.0.0-1.el7.noarch
openstack-nova-cert-12.0.0-1.el7.noarch
openstack-nova-scheduler-12.0.0-1.el7.noarch
Steps to reproduce:
1) Create network with ipv6 subnet.
# neutron net-list
+--+--+---+
| id | name | subnets
|
+--+--+---+
| 286b3e3c-9075-496f-8899-c9890397f087 | net2 |
de602f61-8e05-4337-bc9d-c9f8265bb937 1000:2000::/24 |
| a3931414-73c3-40c9-a39b-d93ae38844a2 | net3 |
b6ce48ab-9387-4128-baa3-4a893dd27bb7 10.0.2.0/24 |
| a5d1181f-bedd-40a5-8b4a-5574b74dba61 | net1 |
72be780a-6df9-47ea-991c-e6fa97396adc 192.168.122.0/24 |
+--+--+---+
2) Create instance with 3 nic
# nova boot \
--flavor 2 \
--image fedora23 \
--config-drive=True \
--nic net-id=a5d1181f-bedd-40a5-8b4a-5574b74dba61 \
--nic net-id=286b3e3c-9075-496f-8899-c9890397f087 \
--nic net-id=a3931414-73c3-40c9-a39b-d93ae38844a2 \
--user-data=/root/cloud-config \
test
# nova list
+--+--+++-+--+
| ID | Name | Status | Task State | Power
State | Networks |
+--+--+++-+--+
| 4f159a96-8154-4946-b2a3-50c2638f545b | test | ACTIVE | - | Running
| net3=10.0.2.116; net2=1000:2000:3000::1102; net1=192.168.122.117 |
+--+--+++-+--+
Logon to instance, mount configDrive:
# mount /dev/disk/by-label/config-2 /mnt/
Actual result:
# cat /mnt/openstack/latest/network_data.json | python3 -m json.tool
{
"links": [
{
"ethernet_mac_address": "fa:16:3e:db:48:10",
"id": "tap54d10236-5d",
"mtu": null,
"type": "ovs",
"vif_id": "54d10236-5d15-4e22-b584-2a185d74b553"
},
{
"ethernet_mac_address": "fa:16:3e:db:c2:96",
"id": "tapae9677cb-32",
"mtu": null,
"type": "ovs",
"vif_id": "ae9677cb-327b-4fc9-9b99-88ebd96595a3"
},
{
"ethernet_mac_address": "fa:16:3e:10:37:07",
"id": "tap1baef501-47",
"mtu": null,
"type": "ovs",
"vif_id": "1baef501-47b0-4c76-928f-34ed2827c7d4"
}
],
"networks": [
{
"id": "network0",
"link": "tap54d10236-5d",
"network_id": "a5d1181f-bedd-40a5-8b4a-5574b74dba61",
"type": "ipv4_dhcp"
},
{
"id": "network1",
"ip_address": "10.0.2.116",
"link": "tap1baef501-47",
"netmask": "255.255.255.0",
"network_id": "a3931414-73c3-40c9-a39b-d93ae38844a2",
"routes": [],
"type": "ipv4"
}
],
"services": []
}
network_data.json provide information about ipv4 adresses only.
Expected result:
network_data.json provide information about all ip adresses.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1514082/+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 1513630] Re: notifications are not being recevied since mitaka
** Also 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/1513630 Title: notifications are not being recevied since mitaka Status in Astara: New Status in neutron: In Progress Bug description: our liberty release was 1 week behind neutron. in that week, we had to pin our gate jobs to stable/liberty for other projects because at some point since mitaka opened, something changed in neutron that prevents events from hitting astara. have not yet been able to track down the change but am in the process of bisecting now. will update this bug with details once i find more To manage notifications about this bug go to: https://bugs.launchpad.net/astara/+bug/1513630/+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 1514095] [NEW] Fails to assign IP addresses if several networks specified
Public bug reported: - Openstack Kilo - centos 7 qcow2 image from cloud.centos.org - Assign 2 networks to the machine and boot. - No IP gets assigned from neither. If I just boot with one network, it works fine. ** Affects: cloud-init Importance: Undecided Status: New ** Attachment added: "console log" https://bugs.launchpad.net/bugs/1514095/+attachment/4514806/+files/cloud-init-nw-issue.log -- 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/1514095 Title: Fails to assign IP addresses if several networks specified Status in cloud-init: New Bug description: - Openstack Kilo - centos 7 qcow2 image from cloud.centos.org - Assign 2 networks to the machine and boot. - No IP gets assigned from neither. If I just boot with one network, it works fine. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1514095/+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 1323975] Re: do not use default=None for config options
** Also affects: rally Importance: Undecided Status: New ** Changed in: rally Assignee: (unassigned) => Shuquan Huang (shuquan) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1323975 Title: do not use default=None for config options Status in Barbican: Fix Released Status in Ceilometer: Fix Released Status in Cinder: In Progress Status in Glance: Fix Released Status in heat: Fix Released Status in Ironic: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in Magnum: In Progress Status in neutron: Fix Released Status in OpenStack Compute (nova): Fix Released Status in oslo-incubator: Fix Released Status in oslo.messaging: Fix Released Status in Rally: New Status in Sahara: Fix Released Status in tempest: In Progress Status in Trove: In Progress Status in zaqar: Fix Released Bug description: In the cfg module default=None is set as the default value. It's not necessary to set it again when defining config options. To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1323975/+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 1323975] Re: do not use default=None for config options
** Also affects: aodh Importance: Undecided Status: New ** Changed in: aodh Assignee: (unassigned) => Shuquan Huang (shuquan) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1323975 Title: do not use default=None for config options Status in Aodh: In Progress Status in Barbican: Fix Released Status in Ceilometer: Fix Released Status in Cinder: In Progress Status in congress: In Progress Status in Glance: Fix Released Status in heat: Fix Released Status in Ironic: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in Magnum: In Progress Status in neutron: Fix Released Status in OpenStack Compute (nova): Fix Released Status in oslo-incubator: Fix Released Status in oslo.messaging: Fix Released Status in Rally: In Progress Status in Sahara: Fix Released Status in tempest: In Progress Status in Trove: In Progress Status in zaqar: Fix Released Bug description: In the cfg module default=None is set as the default value. It's not necessary to set it again when defining config options. To manage notifications about this bug go to: https://bugs.launchpad.net/aodh/+bug/1323975/+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 1514030] Re: /v3/policies response attribute missing
what are you adding this? it's not in the schema [0] or saved in the
backend [1]
0 - https://github.com/openstack/keystone/blob/master/keystone/policy/schema.py
1 -
https://github.com/openstack/keystone/blob/master/keystone/policy/backends/sql.py
i'm not understanding how a project is associated with a policy, at all.
** Changed in: keystone
Status: In Progress => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1514030
Title:
/v3/policies response attribute missing
Status in OpenStack Identity (keystone):
Invalid
Bug description:
{
"policy": {
"blob": "{\"default\": false}",
"id": "c41a4c",
"links": {
"self": "http://identity:35357/v3/policies/c41a4c;
},
"type": "application/json"
}
}
need to update
{
"policy": {
"blob": "{'foobar_user': 'role:compute-user'}",
"project_id": "0426ac1e48f642ef9544c2251e07e261",
"type": "application/json",
"user_id": "0ffd248c55b443eaac5253b4e9cbf9b5"
}
}
project_id is required
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1514030/+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 1323975] Re: do not use default=None for config options
** Also affects: tempest Importance: Undecided Status: New ** Changed in: tempest Assignee: (unassigned) => Shuquan Huang (shuquan) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1323975 Title: do not use default=None for config options Status in Barbican: Fix Released Status in Ceilometer: Fix Released Status in Cinder: In Progress Status in Glance: Fix Released Status in heat: Fix Released Status in Ironic: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in Magnum: In Progress Status in neutron: Fix Released Status in OpenStack Compute (nova): Fix Released Status in oslo-incubator: Fix Released Status in oslo.messaging: Fix Released Status in Sahara: Fix Released Status in tempest: In Progress Status in Trove: In Progress Status in zaqar: Fix Released Bug description: In the cfg module default=None is set as the default value. It's not necessary to set it again when defining config options. To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1323975/+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 1323975] Re: do not use default=None for config options
** Also affects: congress Importance: Undecided Status: New ** Changed in: congress Assignee: (unassigned) => Shuquan Huang (shuquan) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1323975 Title: do not use default=None for config options Status in Barbican: Fix Released Status in Ceilometer: Fix Released Status in Cinder: In Progress Status in congress: New Status in Glance: Fix Released Status in heat: Fix Released Status in Ironic: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in Magnum: In Progress Status in neutron: Fix Released Status in OpenStack Compute (nova): Fix Released Status in oslo-incubator: Fix Released Status in oslo.messaging: Fix Released Status in Rally: In Progress Status in Sahara: Fix Released Status in tempest: In Progress Status in Trove: In Progress Status in zaqar: Fix Released Bug description: In the cfg module default=None is set as the default value. It's not necessary to set it again when defining config options. To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1323975/+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 1514144] [NEW] rpc should return empty list when no l3_plugin is present
Public bug reported:
It is a trivial bug, maybe it is left from a history code change.
In [1], it should be a [] here, instead of {} according to the context.
[1]
https://github.com/openstack/neutron/blob/master/neutron/api/rpc/handlers/l3_rpc.py#L77
** Affects: neutron
Importance: Undecided
Assignee: Hong Hui Xiao (xiaohhui)
Status: In Progress
** Changed in: neutron
Assignee: (unassigned) => Hong Hui Xiao (xiaohhui)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1514144
Title:
rpc should return empty list when no l3_plugin is present
Status in neutron:
In Progress
Bug description:
It is a trivial bug, maybe it is left from a history code change.
In [1], it should be a [] here, instead of {} according to the
context.
[1]
https://github.com/openstack/neutron/blob/master/neutron/api/rpc/handlers/l3_rpc.py#L77
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1514144/+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 1513279] Re: routing with dhcpv6-stateful addressing is broken with DVR
The bug is not valid. Ping6 works fine; was missing the security rule for allowing icmp v6. After adding: neutron security-group-rule-create --protocol icmp --ethertype IPv6 --direction egress 4cf607a6-537f-4893-8531-70ba23895b3d neutron security-group-rule-create --protocol icmp --ethertype IPv6 --direction ingress 4cf607a6-537f-4893-8531-70ba23895b3d the scenario works fine with DVR. @Scollins and folks I regret the inconvenience :( Looks at the bright side; it works with DVR :) ** 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/1513279 Title: routing with dhcpv6-stateful addressing is broken with DVR Status in neutron: Invalid Bug description: Not able to ping v6 address of vm on a different network. With legacy router. Setup has one controller/network node and two compute nodes. Steps: 0. Add security rules to allow ping traffic. neutron security-group-rule-create --protocol icmp --direction ingress 94d41516-dab5-413c-9349-7c9bc3a09e75 1. create two networks. 2. create ipv4 subnet on each (for accessing vm). 3. create ipv6 subnet on each with dhcpv6-stateful addressing. neutron subnet-create dnet1 :1::1/64 --name d6sub1 --enable-dhcp --ip-version 6 --ipv6-ra-mode dhcpv6-stateful --ipv6-address-mode dhcpv6-stateful 4. create a router (not distributed). 5. add interface to router on each of the four subnets. 6. boot a vm on both networks. 7. Log into the guest vm and configure inteface to receive inet6 dhcp address; use dhclient to get v6 address. 8. Ping v6 address of the other guest vm. Fails! ubuntu@dvm11:~$ ping6 :2::4 PING :2::4(:2::4) 56 data bytes From :1::1 icmp_seq=1 Destination unreachable: Address unreachable From :1::1 icmp_seq=2 Destination unreachable: Address unreachable From :1::1 icmp_seq=3 Destination unreachable: Address unreachable Note: As we need to modify interface settings and use dhclient, ubuntu cloud image was used. One may need to set MTU to 1400 for communicating with ubuntu cloud image. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1513279/+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
