date:20160308

[Yahoo-eng-team] [Bug 1551165] Re: delet a vm with macvtap port,port‘s mac did not clean

2016-03-08 Thread Yan Songming

** 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/1551165

Title:
  delet a  vm with macvtap port,port‘s mac did not clean

Status in neutron:
  Invalid

Bug description:
  1 neutron  port-create b9ebf2d9-6823-472f-837f-405dc27d01cc  --name bandwidth 
--binding:vnic-type  macvtap
  Created a new port:
  
+-+--+
  | Field   | Value 
   |
  
+-+--+
  | admin_state_up  | True  
   |
  | binding:host_id |   
   |
  | binding:profile | {}
   |
  | binding:vif_details | {}
   |
  | binding:vif_type| unbound   
   |
  | binding:vnic_type   | macvtap   
   |
  | device_id   |

  2  nova boot --flavor m1.small --image
  2a3e422a-0480-4a73-b6b1-2c15e06ed373 --nic port-id=71d9c5a3-aadc-
  4b29-8e52-17d6028d1b0c instance3

  4  nova delete 70900b6f-5e4c-4830-8f89-4df4f0f14cc4
  Request to delete server 70900b6f-5e4c-4830-8f89-4df4f0f14cc4 has been 
accepted.

  237: enp2s0f0:  mtu 1500 qdisc mq state 
DOWN mode DEFAULT qlen 1000
  link/ether 90:e2:ba:aa:45:a8 brd ff:ff:ff:ff:ff:ff
  vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state auto
  .
  vf 61 MAC 00:00:00:00:00:00, spoof checking on, link-state auto
  vf 62 MAC fa:16:3e:23:b4:10, spoof checking on, link-state auto

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1551165/+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 1554412] [NEW] purge command fails due to foreign key constraint

2016-03-08 Thread Abhishek Kekane

Public bug reported:

In our production environment some how we have encountered a issue in
purge command. One of the example is, purge command fails if image is
deleted but members entry for that particular image is not deleted.

Steps to reproduce:

1. Apply patch https://review.openstack.org/#/c/278870/7 (otherwise you will 
get subquery related error)
2. Run purge command "glance-manage db purge 1 1"

Purge command trace:

2016-03-08 08:25:16.127 CRITICAL glance [req-7ce644e9-3c7d-
4cd4-8377-77f7e1a689a5 None None] DBReferenceError:
(pymysql.err.IntegrityError) (1451, u'Cannot delete or update a parent
row: a foreign key constraint fails (`glance`.`image_locations`,
CONSTRAINT `image_locations_ibfk_1` FOREIGN KEY (`image_id`) REFERENCES
`images` (`id`))') [SQL: u'DELETE FROM images WHERE images.id in (SELECT
T1.id FROM (SELECT images.id \nFROM images \nWHERE images.deleted_at <
%(deleted_at_1)s \n LIMIT %(param_1)s) as T1)'] [parameters:
{u'deleted_at_1': datetime.datetime(2016, 3, 7, 8, 25, 16, 92480),
u'param_1': 1}]

2016-03-08 08:25:16.127 TRACE glance Traceback (most recent call last):
2016-03-08 08:25:16.127 TRACE glance   File "/usr/local/bin/glance-manage", 
line 10, in 
2016-03-08 08:25:16.127 TRACE glance sys.exit(main())
2016-03-08 08:25:16.127 TRACE glance   File 
"/opt/stack/glance/glance/cmd/manage.py", line 344, in main
2016-03-08 08:25:16.127 TRACE glance return 
CONF.command.action_fn(*func_args, **func_kwargs)
2016-03-08 08:25:16.127 TRACE glance   File 
"/opt/stack/glance/glance/cmd/manage.py", line 165, in purge
2016-03-08 08:25:16.127 TRACE glance db_api.purge_deleted_rows(ctx, 
age_in_days, max_rows)
2016-03-08 08:25:16.127 TRACE glance   File 
"/opt/stack/glance/glance/db/sqlalchemy/api.py", line 1327, in 
purge_deleted_rows
2016-03-08 08:25:16.127 TRACE glance result = 
session.execute(delete_statement)
2016-03-08 08:25:16.127 TRACE glance   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 1034, 
in execute
2016-03-08 08:25:16.127 TRACE glance bind, 
close_with_result=True).execute(clause, params or {})
2016-03-08 08:25:16.127 TRACE glance   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 914, 
in execute
2016-03-08 08:25:16.127 TRACE glance return meth(self, multiparams, params)
2016-03-08 08:25:16.127 TRACE glance   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/sql/elements.py", line 323, 
in _execute_on_connection
2016-03-08 08:25:16.127 TRACE glance return 
connection._execute_clauseelement(self, multiparams, params)
2016-03-08 08:25:16.127 TRACE glance   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1010, 
in _execute_clauseelement
2016-03-08 08:25:16.127 TRACE glance compiled_sql, distilled_params
2016-03-08 08:25:16.127 TRACE glance   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1146, 
in _execute_context
2016-03-08 08:25:16.127 TRACE glance context)
2016-03-08 08:25:16.127 TRACE glance   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1337, 
in _handle_dbapi_exception
2016-03-08 08:25:16.127 TRACE glance util.raise_from_cause(newraise, 
exc_info)
2016-03-08 08:25:16.127 TRACE glance   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/util/compat.py", line 200, 
in raise_from_cause
2016-03-08 08:25:16.127 TRACE glance reraise(type(exception), exception, 
tb=exc_tb, cause=cause)
2016-03-08 08:25:16.127 TRACE glance   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1139, 
in _execute_context
2016-03-08 08:25:16.127 TRACE glance context)
2016-03-08 08:25:16.127 TRACE glance   File 
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/default.py", line 
450, in do_execute
2016-03-08 08:25:16.127 TRACE glance cursor.execute(statement, parameters)
2016-03-08 08:25:16.127 TRACE glance   File 
"/usr/local/lib/python2.7/dist-packages/pymysql/cursors.py", line 146, in 
execute
2016-03-08 08:25:16.127 TRACE glance result = self._query(query)
2016-03-08 08:25:16.127 TRACE glance   File 
"/usr/local/lib/python2.7/dist-packages/pymysql/cursors.py", line 296, in _query
2016-03-08 08:25:16.127 TRACE glance conn.query(q)
2016-03-08 08:25:16.127 TRACE glance   File 
"/usr/local/lib/python2.7/dist-packages/pymysql/connections.py", line 819, in 
query
2016-03-08 08:25:16.127 TRACE glance self._affected_rows = 
self._read_query_result(unbuffered=unbuffered)
2016-03-08 08:25:16.127 TRACE glance   File 
"/usr/local/lib/python2.7/dist-packages/pymysql/connections.py", line 1001, in 
_read_query_result
2016-03-08 08:25:16.127 TRACE glance result.read()
2016-03-08 08:25:16.127 TRACE glance   File 
"/usr/local/lib/python2.7/dist-packages/pymysql/connections.py", line 1285, in 
read
2016-03-08 08:25:16.127 TRACE glance first_packet = 
self.connection._read_packet()
2016-03-08 08:25:16.127 TRACE glance   File 
"/usr/loca

[Yahoo-eng-team] [Bug 1554414] [NEW] Avoid calling _get_subnet(s) multiple times in ipam driver

2016-03-08 Thread venkata anil

Public bug reported:

While allocating or updating ips for port, _get_subnet and _get_subents
are called multiple times.

For example, if update_port is called with below fixed_ips
fixed_ips = [{'subnet_id': 'subnet1'},
 {'subnet_id': 'v6_dhcp_stateless_subnet'}
 {'subnet_id': 'v6_slaac_subnet'}
 {'subnet_id': 'v6_pd_subnet'}
 {'subnet_id': 'subnet4', 'ip_address': '30.0.0.3'}
 {'ip_address': '40.0.0.4'}
 {'ip_address': '50.0.0.5'}}
then through _test_fixed_ips_for_port(fixed_ips),  "_get_subnet"[1] is called 4 
times for subnet1, v6_dhcp_stateless_subnet, v6_slaac_subnet, v6_pd_subnet, 
subnet4. "_get_subnets" [2] is called 2 times for ip_address 40.0.0.4 and 
50.0.0.5.


If in case of _test_fixed_ips_for_port called for _allocate_ips_for_port, then 
_get_subnets is already called at[3] (so increase call count). So incase of 
_allocate_ips_for_port, if we save subnets from [3] saved in local variable and 
use that in-memory subnets in further calls, we can avoid above calls to DB.


Sometimes when subnet is updated, update_subnet may trigger 
update_port(fixed_ips)[4] for all ports on the subnet. And in each port's 
fixed_ips, if we have multiple subnets and ip_addresses then _get_subnet and 
_get_subnets will be called for multiple times for each port like above 
example. For example in above case if we have 10 ports on the subnet, then 
update_subnet will result in (10*6=60) 60 times DB access instead of 10 DB 
access. 


When port_update is called for PD subnet, it again calls get_subnet for each 
fixed_ip[5], to check if subnet is PD subnet or not(after get_subnet and 
get_subnets called many times in _test_fixed_ips_for_port).


In all above cases, for _get_subnet and _get_subnets, we are accessing DB many 
times.
 So instead of calling get_subnet or get_subnets for each fixed_ip of a port(at 
multiple places), we can call get_subnets of a network at begining of 
_allocate_ips_for_port(for create port) and _update_ips_for_port(during update) 
and use the in-memory subnets in subsequent private functions.


[1] 
https://github.com/openstack/neutron/blob/master/neutron/db/ipam_backend_mixin.py#L311
[2] 
https://github.com/openstack/neutron/blob/master/neutron/db/ipam_backend_mixin.py#L331
[3] 
https://github.com/openstack/neutron/blob/master/neutron/db/ipam_pluggable_backend.py#L192
[4] 
https://github.com/openstack/neutron/blob/master/neutron/db/db_base_plugin_v2.py#L785
[5] 
https://review.openstack.org/#/c/241227/11/neutron/db/ipam_non_pluggable_backend.py
 Lines 284 and 334.

** Affects: neutron
 Importance: Undecided
 Assignee: venkata anil (anil-venkata)
 Status: New


** Tags: ipv6 l3-ipam-dhcp

** Changed in: neutron
 Assignee: (unassigned) => venkata anil (anil-venkata)

** Tags added: ipv6 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/1554414

Title:
  Avoid calling _get_subnet(s) multiple times in ipam driver

Status in neutron:
  New

Bug description:
  While allocating or updating ips for port, _get_subnet and
  _get_subents are called multiple times.

  For example, if update_port is called with below fixed_ips
  fixed_ips = [{'subnet_id': 'subnet1'},
   {'subnet_id': 'v6_dhcp_stateless_subnet'}
   {'subnet_id': 'v6_slaac_subnet'}
   {'subnet_id': 'v6_pd_subnet'}
   {'subnet_id': 'subnet4', 'ip_address': '30.0.0.3'}
   {'ip_address': '40.0.0.4'}
   {'ip_address': '50.0.0.5'}}
  then through _test_fixed_ips_for_port(fixed_ips),  "_get_subnet"[1] is called 
4 times for subnet1, v6_dhcp_stateless_subnet, v6_slaac_subnet, v6_pd_subnet, 
subnet4. "_get_subnets" [2] is called 2 times for ip_address 40.0.0.4 and 
50.0.0.5.

  
  If in case of _test_fixed_ips_for_port called for _allocate_ips_for_port, 
then _get_subnets is already called at[3] (so increase call count). So incase 
of _allocate_ips_for_port, if we save subnets from [3] saved in local variable 
and use that in-memory subnets in further calls, we can avoid above calls to DB.

  
  Sometimes when subnet is updated, update_subnet may trigger 
update_port(fixed_ips)[4] for all ports on the subnet. And in each port's 
fixed_ips, if we have multiple subnets and ip_addresses then _get_subnet and 
_get_subnets will be called for multiple times for each port like above 
example. For example in above case if we have 10 ports on the subnet, then 
update_subnet will result in (10*6=60) 60 times DB access instead of 10 DB 
access. 

  
  When port_update is called for PD subnet, it again calls get_subnet for each 
fixed_ip[5], to check if subnet is PD subnet or not(after get_subnet and 
get_subnets called many times in _test_fixed_ips_for_port).

  
  In all above cases, for _get_subnet and _get_subnets, we are accessing DB 
many times.
   So instead of calling

[Yahoo-eng-team] [Bug 1554339] Re: ComputeCapabilitiesFilter failed to work with AggregateInstanceExtraSpecsFilter

2016-03-08 Thread wuhao

** Changed in: nova
Status: In Progress => 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/1554339

Title:
ComputeCapabilitiesFilter failed to work with
AggregateInstanceExtraSpecsFilter

Status in OpenStack Compute (nova):
Invalid

Bug description:
Currently, ComputeCapabilitiesFilter returns false if 'extra_specs'
can't retrieve in the host state. And,
AggregateInstanceExtraSpecsFilter also use extra_specs to create new
instance in a host aggregate. The problem is they failed to select any
destinations, when the key is in non-scope format. As is shown in,

https://github.com/openstack/nova/blob/master/nova/scheduler/filters/compute_capabilities_filter.py#L77.

For example, we may want to use host aggregate to create a new
instance in some servers with specified properties. So we create a new
flavor and set 'extra_specs' to {"property": "balabala"}，the
computecapabilitiesfilter will return false. In this situation,
ComputeCapabilitiesFilter failed to work with
AggregateInstanceExtraSpecsFilter

I think we'd better check the capabilities only when the key for the
filter is scope format in capabilities scope (i.e.
capabilities:xxx:yyy), rather than non-scope format (i.e. no :
contained).

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1554339/+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

86 matches

Mail list logo