[Yahoo-eng-team] [Bug 1458477] [NEW] Flavors are not sorted when launching instance
Public bug reported: When you click on Instances - Launch Instance then values of flavors in drop down menu are not sorted. I have 16 flavors and it is already hard for me to find correct one. It would be nice if this form's field can be sorted by alphabet. I found this in OS Icehouse. ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1458477 Title: Flavors are not sorted when launching instance Status in OpenStack Dashboard (Horizon): New Bug description: When you click on Instances - Launch Instance then values of flavors in drop down menu are not sorted. I have 16 flavors and it is already hard for me to find correct one. It would be nice if this form's field can be sorted by alphabet. I found this in OS Icehouse. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1458477/+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 1458471] [NEW] get_router_for_floatingip does not check if router is default gateway
Public bug reported: In the function db._get_router_for_floatingip() we check that the router has a suitable gateway IP, but we do not check if that router is the default gateway for that subnet. When multiple routers exist with ip addresses in both the subnet for the instance, plus the gateway subnet, the function returns the first router it finds rather than the one that instances are using as default gateway. Can we check a condition such as router_gw_qry.floating_ip == subnet_db['gateway_ip'] in addition to checking has_gw_port? ** 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/1458471 Title: get_router_for_floatingip does not check if router is default gateway Status in OpenStack Neutron (virtual network service): New Bug description: In the function db._get_router_for_floatingip() we check that the router has a suitable gateway IP, but we do not check if that router is the default gateway for that subnet. When multiple routers exist with ip addresses in both the subnet for the instance, plus the gateway subnet, the function returns the first router it finds rather than the one that instances are using as default gateway. Can we check a condition such as router_gw_qry.floating_ip == subnet_db['gateway_ip'] in addition to checking has_gw_port? To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1458471/+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 1458498] [NEW] Authenticated URLs not accepted when Launching stacks
Public bug reported: When trying to launch a new heat stack from horizon using URL input, the input validation seemingly only accepts a standard URL (e.g. https://domain.com/path/to/template.yaml). However, if a URL contains login credentials (e.g. https://user:passw...@domain.com/path/to/template.yaml), the input validation throws Enter a valid URL. The URL is valid and can be curl'd etc, and while passing credentials like that may not be the safest, in an isolated network it is sometimes done. Horizon shouldn't prevent these types of URLs being entered. ** Affects: horizon Importance: Undecided Status: New ** Tags: heat ** Description changed: - If trying to launch a new heat stack from horizon, using URL input, the input validation seemingly only accepts a standard URL (e.g. https://domain.com/path/to/template.yaml). + When trying to launch a new heat stack from horizon using URL input, the input validation seemingly only accepts a standard URL (e.g. https://domain.com/path/to/template.yaml). However, if a URL contains login credentials (e.g. https://user:passw...@domain.com/path/to/template.yaml), the input validation throws Enter a valid URL. The URL is valid and can be curl'd etc, and while passing credentials like that may not be the safest, in an isolated network it is sometimes done. Horizon shouldn't prevent these types of URLs being entered. -- 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/1458498 Title: Authenticated URLs not accepted when Launching stacks Status in OpenStack Dashboard (Horizon): New Bug description: When trying to launch a new heat stack from horizon using URL input, the input validation seemingly only accepts a standard URL (e.g. https://domain.com/path/to/template.yaml). However, if a URL contains login credentials (e.g. https://user:passw...@domain.com/path/to/template.yaml), the input validation throws Enter a valid URL. The URL is valid and can be curl'd etc, and while passing credentials like that may not be the safest, in an isolated network it is sometimes done. Horizon shouldn't prevent these types of URLs being entered. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1458498/+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 1458541] [NEW] Decomposite DVR router compute node and network node functionallity to two classes
Public bug reported: Currently the same dvr router class is used both by the L3 Agent in the compute nodes that is responsible for the virtual routers namespace and the fip namespace and also used by the centralized SNAT L3 Agent in the network node. This bug address splitting the above functionality into two different classes ** Affects: neutron Importance: Undecided Assignee: Gal Sagie (gal-sagie) Status: New ** Changed in: neutron Assignee: (unassigned) = Gal Sagie (gal-sagie) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1458541 Title: Decomposite DVR router compute node and network node functionallity to two classes Status in OpenStack Neutron (virtual network service): New Bug description: Currently the same dvr router class is used both by the L3 Agent in the compute nodes that is responsible for the virtual routers namespace and the fip namespace and also used by the centralized SNAT L3 Agent in the network node. This bug address splitting the above functionality into two different classes To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1458541/+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 1456228] Re: Trusted vm can be powered on untrusted host
Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions. Can a Nova core confirm that report ? ** Also affects: ossa Importance: Undecided Status: New ** Changed in: ossa Status: New = Incomplete -- 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/1456228 Title: Trusted vm can be powered on untrusted host Status in OpenStack Compute (Nova): New Status in OpenStack Security Advisories: Incomplete Bug description: This is related to the trusted compute. I recently setup trusted compute pool in my company and have observed that although new trusted vm is not able to be launched from an untrusted host, but if an trusted vm that have launched earlier on a trusted host which is compromised later on, that VM can still be powered on. 1. Exact version of Nova/Openstack: [root@grunt2 ~]# rpm -qa | grep nova python-nova-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-network-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-compute-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-conductor-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-cells-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-api-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-console-2014.1.2-100+45c2cbc.fc20.noarch python-novaclient-2.17.0-2.fc21.noarch openstack-nova-cert-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-scheduler-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-objectstore-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-common-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-novncproxy-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-doc-2014.1.2-100+45c2cbc.fc20.noarch 2. Relevant log files: this is not a error, don't think logs will help.. 3. Reproduce steps: * create trusted compute pool with only one compute node * create an trusted VM on that compute node * compromise the trusted compute node by changing the boot order * power on the trusted Vm created earlier. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1456228/+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 1458570] [NEW] No validation for IP Address , when Member is created
Public bug reported: When a Member is created, it is possible to give any IP Address. Validation needs to be done , so that only the IP Address of the Instances to be given. Also During Pool Creation, External Subnet should not be assigned to a pool. Only Internal Subnets to be assigned. Validation needs to be done for Pool-Create and Member-Create ** Affects: neutron Importance: Undecided Assignee: senthilmageswaran (senthilmageswaran-muthusamy) Status: New ** Tags: lbaas ** Changed in: neutron Assignee: (unassigned) = senthilmageswaran (senthilmageswaran-muthusamy) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1458570 Title: No validation for IP Address , when Member is created Status in OpenStack Neutron (virtual network service): New Bug description: When a Member is created, it is possible to give any IP Address. Validation needs to be done , so that only the IP Address of the Instances to be given. Also During Pool Creation, External Subnet should not be assigned to a pool. Only Internal Subnets to be assigned. Validation needs to be done for Pool-Create and Member-Create To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1458570/+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 1458682] [NEW] neutron-db-manage autogenerate does not produce a clean upgrade
Public bug reported: neutron-db-manage --autogenerate create commands to drop all the tables without models in the neutron tree. All the FWaaS, LBaaS and VPNaaS tables have models in separate repos. This means that people who just want to add/change some tables will get a lot of unwanted commands in their autogenerated migration script. ** Affects: neutron Importance: Undecided Assignee: Henry Gessau (gessau) Status: New ** Tags: db ** Changed in: neutron Assignee: (unassigned) = Henry Gessau (gessau) ** Tags added: db -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1458682 Title: neutron-db-manage autogenerate does not produce a clean upgrade Status in OpenStack Neutron (virtual network service): New Bug description: neutron-db-manage --autogenerate create commands to drop all the tables without models in the neutron tree. All the FWaaS, LBaaS and VPNaaS tables have models in separate repos. This means that people who just want to add/change some tables will get a lot of unwanted commands in their autogenerated migration script. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1458682/+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 1377997] Re: All combinations of IPv6 subnet modes need to be tested
** Changed in: neutron Status: In Progress = 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/1377997 Title: All combinations of IPv6 subnet modes need to be tested Status in OpenStack Neutron (virtual network service): Fix Released Bug description: On subnets, the attributes ipv6_ra_mode ipv6_address_mode can have values slaac dhcpv6_stateless dhcpv6_statefull None or not be specified. All combinations of the above need to be tested, for both create_subnet and update_subnet. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1377997/+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 1458697] [NEW] Horizon/Dashboard source reorganisation
Public bug reported: The intent with Horizon has always been that the horizon component be a library/framework of components for dashboards to be built out of, and the openstack_dashboard component be an implementation of that. For the purposes of succintness, framework in the below will refer to the folder horizon/horizon and dashboard will refer to horizon/openstack_dashboard. Perhaps one day those could be renamed also... Some reorganisation work has been done in bug https://bugs.launchpad.net/horizon/+bug/1454880 but it has focused on cleaning up the angularjs usage in our codebase. During that work, several points were identified as blurring the line between framework and dashboard in the codebase, and this bug captures those. NOTE that this bug refers to the codebase *once that refactoring has been done* and leaf patch https://review.openstack.org/#/c/184597/ has been merged. Patches relating to this bug will all depend on that patch until it is merged. Changes needing to be made: 1) the framework should not define the top-level angular app, and thus horizon/static/dashboard-app should go away, with parts moving to the dashboard and framework as appropriate. 2) the framework should also not define the top-level HTML (base.html) - this should be in the dashboard. Actual steps to perform: 1) horizon/static/dashboard-app/utils should be moved to a new location in the framework. There's a large amount of tech debt in this folder which should be addressed in subsequent bugs and these files removed. 2) horizon/static/dashboard-app/login is a generic login/auth helper component should be moved to the framework. 3) horizon/static/dashboard-app/controllers has several controllers only used in the dashboard so should be moved there. The single controller dummy.js should remain in the framework. 4) horizon/static/dashboard-app/dashboard-app.module.js is the top-level angular app and should move to the dashboard. 5) horizon/templates/base.html should move to dashboard and its dependencies horizon/templates/horizon/_conf.html and horizon/templates/horizon/_scripts.html should move with it. There remains a need for a horizon/templates/horizon/_scripts.html in the framework for testing purposes, so a new file for that purpose will be placed in the testing area of the framework. On the utils tech debt: the contents of that folder are only used in one place; the functions defined there should be moved to the modules they're used in. Those target modules are legacy code which will be replaced over time by angularjs implementations, so I believe it is reasonable to do this. ** Affects: horizon Importance: Undecided Assignee: Richard Jones (r1chardj0n3s) Status: In Progress -- 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/1458697 Title: Horizon/Dashboard source reorganisation Status in OpenStack Dashboard (Horizon): In Progress Bug description: The intent with Horizon has always been that the horizon component be a library/framework of components for dashboards to be built out of, and the openstack_dashboard component be an implementation of that. For the purposes of succintness, framework in the below will refer to the folder horizon/horizon and dashboard will refer to horizon/openstack_dashboard. Perhaps one day those could be renamed also... Some reorganisation work has been done in bug https://bugs.launchpad.net/horizon/+bug/1454880 but it has focused on cleaning up the angularjs usage in our codebase. During that work, several points were identified as blurring the line between framework and dashboard in the codebase, and this bug captures those. NOTE that this bug refers to the codebase *once that refactoring has been done* and leaf patch https://review.openstack.org/#/c/184597/ has been merged. Patches relating to this bug will all depend on that patch until it is merged. Changes needing to be made: 1) the framework should not define the top-level angular app, and thus horizon/static/dashboard-app should go away, with parts moving to the dashboard and framework as appropriate. 2) the framework should also not define the top-level HTML (base.html) - this should be in the dashboard. Actual steps to perform: 1) horizon/static/dashboard-app/utils should be moved to a new location in the framework. There's a large amount of tech debt in this folder which should be addressed in subsequent bugs and these files removed. 2) horizon/static/dashboard-app/login is a generic login/auth helper component should be moved to the framework. 3) horizon/static/dashboard-app/controllers has several controllers only used in the dashboard so should be moved there. The single controller dummy.js should remain in the framework. 4) horizon/static/dashboard-app/dashboard-app.module.js is the
[Yahoo-eng-team] [Bug 1457759] Re: Wrong oslo message keystone_authtoken username
Already fixed in oslo.config review https://review.openstack.org/#/c/169392/ ** Project changed: nova = oslo.config -- 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/1457759 Title: Wrong oslo message keystone_authtoken username Status in Oslo configuration management library: New Bug description: The following line appears in my api-log: 2015-05-22 08:46:55.205 2579 WARNING oslo_config.cfg [-] Option username from group keystone_authtoken is deprecated. Use option username from group keystone_authtoken. the corresponding configuration: [keystone_authtoken] [...] username = nova [...] So this warning is not correct and confuses. To manage notifications about this bug go to: https://bugs.launchpad.net/oslo.config/+bug/1457759/+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 1458712] [NEW] unhashable type 'list' in local vlan restoration code
Public bug reported: unhashable type 'list' in local vlan restoration code when db_get_val doesn't find an entry for a port. ** Affects: neutron Importance: Undecided Assignee: Kevin Benton (kevinbenton) 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/1458712 Title: unhashable type 'list' in local vlan restoration code Status in OpenStack Neutron (virtual network service): In Progress Bug description: unhashable type 'list' in local vlan restoration code when db_get_val doesn't find an entry for a port. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1458712/+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 1458702] [NEW] Rename mis-named framwork.util.form module
Public bug reported: In patch https://review.openstack.org/#/c/182909/ it was noticed that the framework.util.form module is possibly mis-named (and mis-located). The module contains a single directive which is actually a validator for password/confirm input field contents checking (actually any two input fields, but that's the only real use-case). This directive should move to the horizon.util.validators module. ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1458702 Title: Rename mis-named framwork.util.form module Status in OpenStack Dashboard (Horizon): New Bug description: In patch https://review.openstack.org/#/c/182909/ it was noticed that the framework.util.form module is possibly mis-named (and mis- located). The module contains a single directive which is actually a validator for password/confirm input field contents checking (actually any two input fields, but that's the only real use-case). This directive should move to the horizon.util.validators module. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1458702/+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 1458709] [NEW] ovs agent can't startup in some abnormal condition
Public bug reported:
when ovs agent restart, it will restore the local vlan map in function
'_restore_local_vlan_map',
def _restore_local_vlan_map(self):
cur_ports = self.int_br.get_vif_ports()
for port in cur_ports:
local_vlan_map = self.int_br.db_get_val(Port, port.port_name,
other_config)
local_vlan = self.int_br.db_get_val(Port, port.port_name, tag)
net_uuid = local_vlan_map.get('net_uuid')
if (net_uuid and net_uuid not in self.local_vlan_map
and local_vlan != DEAD_VLAN_TAG):
self.provision_local_vlan(local_vlan_map['net_uuid'],
local_vlan_map['network_type'],
local_vlan_map['physical_network'],
local_vlan_map['segmentation_id'],
local_vlan)
in some abnormal condition, if a device does not be set tag in ovsdb,
the 'self.int_br.db_get_val(Port, port.port_name, tag)' will return
a empty list, so in function 'provision_local_vlan' will raise
exception:
def provision_local_vlan(self, net_uuid, network_type, physical_network,
segmentation_id,local_vlan=None:
lvm = self.local_vlan_map.get(net_uuid)
if lvm:
lvid = lvm.vlan
else:
if local_vlan in self.available_local_vlans:
lvid = local_vlan
self.available_local_vlans.remove(local_vlan)
this line will raise exception 'if local_vlan in
self.available_local_vlans'
** Affects: neutron
Importance: Undecided
Assignee: shihanzhang (shihanzhang)
Status: New
** Description changed:
when ovs agent restart, it will restore the local vlan map in function
'_restore_local_vlan_map',
- def _restore_local_vlan_map(self):
- cur_ports = self.int_br.get_vif_ports()
- for port in cur_ports:
- local_vlan_map = self.int_br.db_get_val(Port, port.port_name,
- other_config)
- local_vlan = self.int_br.db_get_val(Port, port.port_name, tag)
- net_uuid = local_vlan_map.get('net_uuid')
- if (net_uuid and net_uuid not in self.local_vlan_map
- and local_vlan != DEAD_VLAN_TAG):
- self.provision_local_vlan(local_vlan_map['net_uuid'],
- local_vlan_map['network_type'],
- local_vlan_map['physical_network'],
- local_vlan_map['segmentation_id'],
- local_vlan)
- in some abnormal condition, if a device does not be set tag in ovsdb, the
'self.int_br.db_get_val(Port, port.port_name, tag)' will return a empty
list, so in function 'provision_local_vlan' will raise exception:
+ def _restore_local_vlan_map(self):
+ cur_ports = self.int_br.get_vif_ports()
+ for port in cur_ports:
+ local_vlan_map = self.int_br.db_get_val(Port, port.port_name,
+ other_config)
+ local_vlan = self.int_br.db_get_val(Port, port.port_name, tag)
+ net_uuid = local_vlan_map.get('net_uuid')
+ if (net_uuid and net_uuid not in self.local_vlan_map
+ and local_vlan != DEAD_VLAN_TAG):
+ self.provision_local_vlan(local_vlan_map['net_uuid'],
+ local_vlan_map['network_type'],
+ local_vlan_map['physical_network'],
+ local_vlan_map['segmentation_id'],
+ local_vlan)
- def provision_local_vlan(self, net_uuid, network_type, physical_network,
- segmentation_id, local_vlan=None):
- lvm = self.local_vlan_map.get(net_uuid)
- if lvm:
- lvid = lvm.vlan
- else:
- if local_vlan in self.available_local_vlans:
- lvid = local_vlan
- self.available_local_vlans.remove(local_vlan)
- this line will raise exception 'if local_vlan in self.available_local_vlans'
+ in some abnormal condition, if a device does not be set tag in ovsdb,
+ the 'self.int_br.db_get_val(Port, port.port_name, tag)' will return
+ a empty list, so in function 'provision_local_vlan' will raise
+ exception:
+
+ def provision_local_vlan(self, net_uuid, network_type, physical_network,
+ segmentation_id,local_vlan=None:
+ lvm = self.local_vlan_map.get(net_uuid)
+ if lvm:
+ lvid = lvm.vlan
+ else:
+ if local_vlan in self.available_local_vlans:
+ lvid = local_vlan
+ self.available_local_vlans.remove(local_vlan)
+
+ this line will raise exception 'if local_vlan in
+
[Yahoo-eng-team] [Bug 1458718] [NEW] DB2 error occurs when neutron server enables multiple api works
Public bug reported: When neutron server enables multiple api workers, it will use os.fork to start multiple neutron server process. During this period, some DB2 error will occur as below, which shows we are trying to close a closed connection. It seems like that pooled connection is shared by processes. 2015-04-29 22:27:39.330 567 ERROR sqlalchemy.pool.QueuePool [-] Exception closing connection ibm_db_dbi.Connection object at 0x469a190 2015-04-29 22:27:39.330 567 TRACE sqlalchemy.pool.QueuePool Traceback (most recent call last): 2015-04-29 22:27:39.330 567 TRACE sqlalchemy.pool.QueuePool File /usr/lib64/python2.7/site-packages/sqlalchemy/pool.py, line 250, in _close_connection 2015-04-29 22:27:39.330 567 TRACE sqlalchemy.pool.QueuePool self._dialect.do_close(connection) 2015-04-29 22:27:39.330 567 TRACE sqlalchemy.pool.QueuePool File /usr/lib64/python2.7/site-packages/sqlalchemy/engine/default.py, line 412, in do_close 2015-04-29 22:27:39.330 567 TRACE sqlalchemy.pool.QueuePool dbapi_connection.close() 2015-04-29 22:27:39.330 567 TRACE sqlalchemy.pool.QueuePool File /usr/lib64/python2.7/site-packages/ibm_db_dbi.py, line 688, in close 2015-04-29 22:27:39.330 567 TRACE sqlalchemy.pool.QueuePool raise _get_exception(inst) 2015-04-29 22:27:39.330 567 TRACE sqlalchemy.pool.QueuePool OperationalError: ibm_db_dbi::OperationalError: [IBM][CLI Driver] CLI0106E Connection is closed. SQLSTATE=08003 SQLCODE=-9 Currently neutron is using dispose() in child process to release the connnection and create new one. Actually we should close connection is father process before os.fork and create a separate engine for each child process. Reference to sqlalchemy doc(http://docs.sqlalchemy.org/en/latest/core/connections.html#basic- usage) ** Affects: neutron Importance: Undecided Assignee: Zhang Gong (zhanggbj) Status: New ** Changed in: neutron Assignee: (unassigned) = Zhang Gong (zhanggbj) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1458718 Title: DB2 error occurs when neutron server enables multiple api works Status in OpenStack Neutron (virtual network service): New Bug description: When neutron server enables multiple api workers, it will use os.fork to start multiple neutron server process. During this period, some DB2 error will occur as below, which shows we are trying to close a closed connection. It seems like that pooled connection is shared by processes. 2015-04-29 22:27:39.330 567 ERROR sqlalchemy.pool.QueuePool [-] Exception closing connection ibm_db_dbi.Connection object at 0x469a190 2015-04-29 22:27:39.330 567 TRACE sqlalchemy.pool.QueuePool Traceback (most recent call last): 2015-04-29 22:27:39.330 567 TRACE sqlalchemy.pool.QueuePool File /usr/lib64/python2.7/site-packages/sqlalchemy/pool.py, line 250, in _close_connection 2015-04-29 22:27:39.330 567 TRACE sqlalchemy.pool.QueuePool self._dialect.do_close(connection) 2015-04-29 22:27:39.330 567 TRACE sqlalchemy.pool.QueuePool File /usr/lib64/python2.7/site-packages/sqlalchemy/engine/default.py, line 412, in do_close 2015-04-29 22:27:39.330 567 TRACE sqlalchemy.pool.QueuePool dbapi_connection.close() 2015-04-29 22:27:39.330 567 TRACE sqlalchemy.pool.QueuePool File /usr/lib64/python2.7/site-packages/ibm_db_dbi.py, line 688, in close 2015-04-29 22:27:39.330 567 TRACE sqlalchemy.pool.QueuePool raise _get_exception(inst) 2015-04-29 22:27:39.330 567 TRACE sqlalchemy.pool.QueuePool OperationalError: ibm_db_dbi::OperationalError: [IBM][CLI Driver] CLI0106E Connection is closed. SQLSTATE=08003 SQLCODE=-9 Currently neutron is using dispose() in child process to release the connnection and create new one. Actually we should close connection is father process before os.fork and create a separate engine for each child process. Reference to sqlalchemy doc(http://docs.sqlalchemy.org/en/latest/core/connections.html#basic- usage) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1458718/+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
