[Yahoo-eng-team] [Bug 1596829] Re: String interpolation should be delayed at logging calls

[OpenStack Infra]

Reviewed:  https://review.openstack.org/339268
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=5cef3f726e00ab2b22e3eca2b1050a431547fb85
Submitter: Jenkins
Branch:master

commit 5cef3f726e00ab2b22e3eca2b1050a431547fb85
Author: Takashi NATSUME 
Date:   Thu Jul 7 22:19:33 2016 +0900

Add a hacking rule for string interpolation at logging

String interpolation should be delayed to be handled
by the logging code, rather than being done
at the point of the logging call.
So add a hacking rule for it.

See the oslo i18n guideline.

* http://docs.openstack.org/developer/oslo.i18n/guidelines.html

Change-Id: I91e8d59d508c594256d5f74514e62f8f928d1df5
Closes-Bug: #1596829


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

Title:
  String interpolation should be delayed at logging calls

Status in Ceilometer:
  New
Status in Cinder:
  New
Status in Glance:
  New
Status in glance_store:
  New
Status in heat:
  New
Status in Ironic:
  New
Status in OpenStack Identity (keystone):
  New
Status in neutron:
  Fix Released
Status in OpenStack Compute (nova):
  In Progress
Status in os-brick:
  New
Status in python-cinderclient:
  New
Status in python-glanceclient:
  New
Status in OpenStack Object Storage (swift):
  New
Status in taskflow:
  New

Bug description:
  String interpolation should be delayed to be handled by the logging
  code, rather than being done at the point of the logging call.

  Wrong: LOG.debug('Example: %s' % 'bad')
  Right: LOG.debug('Example: %s', 'good')

  See the following guideline.

  * http://docs.openstack.org/developer/oslo.i18n/guidelines.html
  #adding-variables-to-log-messages

  The rule for it should be added to hacking checks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1596829/+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 1602113] [NEW] Needs to point Image Service API documention

[Atsushi SAKAI]

Public bug reported:

Need to point the API documentation. or describe in api-ref itself.


Image metadata is updated by passing HTTP headers prefixed with one of the 
strings x-image-meta- or x-image-meta-property-. See the API documentation for 
details.

http://developer.openstack.org/api-ref/image/v1/index.html?expanded=update-image-detail#update-image

** Affects: glance
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1602113

Title:
  Needs to point Image Service API documention

Status in Glance:
  New

Bug description:
  Need to point the API documentation. or describe in api-ref itself.

  
  Image metadata is updated by passing HTTP headers prefixed with one of the 
strings x-image-meta- or x-image-meta-property-. See the API documentation for 
details.
  
  
http://developer.openstack.org/api-ref/image/v1/index.html?expanded=update-image-detail#update-image

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1602113/+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 1596829] Re: String interpolation should be delayed at logging calls

[haobing1]

** Also affects: taskflow
   Importance: Undecided
   Status: New

** Changed in: taskflow
 Assignee: (unassigned) => haobing1 (haobing1)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1596829

Title:
  String interpolation should be delayed at logging calls

Status in Ceilometer:
  New
Status in Cinder:
  New
Status in Glance:
  New
Status in glance_store:
  New
Status in heat:
  New
Status in Ironic:
  New
Status in OpenStack Identity (keystone):
  New
Status in neutron:
  In Progress
Status in OpenStack Compute (nova):
  In Progress
Status in os-brick:
  New
Status in python-cinderclient:
  New
Status in python-glanceclient:
  New
Status in OpenStack Object Storage (swift):
  New
Status in taskflow:
  New

Bug description:
  String interpolation should be delayed to be handled by the logging
  code, rather than being done at the point of the logging call.

  Wrong: LOG.debug('Example: %s' % 'bad')
  Right: LOG.debug('Example: %s', 'good')

  See the following guideline.

  * http://docs.openstack.org/developer/oslo.i18n/guidelines.html
  #adding-variables-to-log-messages

  The rule for it should be added to hacking checks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1596829/+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 1602081] Re: Use oslo.context's policy dict

[haobing1]

** Also affects: taskflow
   Importance: Undecided
   Status: New

** Changed in: taskflow
 Assignee: (unassigned) => haobing1 (haobing1)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1602081

Title:
  Use oslo.context's policy dict

Status in Cinder:
  In Progress
Status in Glance:
  New
Status in heat:
  In Progress
Status in neutron:
  New
Status in OpenStack Compute (nova):
  New
Status in taskflow:
  New

Bug description:
  This is a cross project goal to standardize the values available to
  policy writers and to improve the basic oslo.context object. It is
  part of the follow up work to bug #1577996 and bug #968696.

  There has been an ongoing problem for how we define the 'admin' role.
  Because tokens are project scoped having the 'admin' role on any
  project granted you the 'admin' role on all of OpenStack. As a
  solution to this keystone defined an is_admin_project field so that
  keystone defines a single project that your token must be scoped to to
  perform admin operations. This has been implemented.

  The next phase of this is to make all the projects understand the X
  -Is-Admin-Project header from keystonemiddleware and pass it to
  oslo_policy. However this pattern of keystone changes something and
  then goes to every project to fix it has been repeated a number of
  times now and we would like to make it much more automatic.

  Ongoing work has enhanced the base oslo.context object to include both
  the load_from_environ and to_policy_values methods. The
  load_from_environ classmethod takes an environment dict with all the
  standard auth_token and oslo middleware headers and loads them into
  their standard place on the context object.

  The to_policy_values() then creates a standard credentials dictionary
  with all the information that should be required to enforce policy
  from the context. The combination of these two methods means in future
  when authentication information needs to be passed to policy it can be
  handled entirely by oslo.context and does not require changes in each
  individual service.

  Note that in future a similar pattern will hopefully be employed to
  simplify passing authentication information over RPC to solve the
  timeout issues. This is a prerequisite for that work.

  There are a few common problems in services that are required to make
  this work:

  1. Most service context.__init__ functions take and discard **kwargs.
  This is so if the context.from_dict receives arguments it doesn't know
  how to handle (possibly because new things have been added to the base
  to_dict) it ignores them. Unfortunately to make the load_from_environ
  method work we need to pass parameters to __init__ that are handled by
  the base class.

  To make this work we simply have to do a better job of using
  from_dict. Instead of passing everything to __init__ and ignoring what
  we don't know we have from_dict extract only the parameters that
  context knows how to use and call __init__ with those.

  2. The parameters passed to the base context.__init__ are old.
  Typically they are user and tenant where most services expect user_id
  and project_id. There is ongoing work to improve this in oslo.context
  but for now we have to ensure that the subclass correctly sets and
  uses the right variable names.

  3. Some services provide additional information to the policy
  enforcement method. To continue to make this function we will simply
  override the to_policy_values method in the subclasses.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1602081/+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 1530331] Re: [RFE] [ipv6] Advertise tenant prefixes from router to outside

[Launchpad Bug Tracker]

[Expired for neutron because there has been no activity for 60 days.]

** Changed in: neutron
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1530331

Title:
  [RFE] [ipv6] Advertise tenant prefixes from router to outside

Status in neutron:
  Expired

Bug description:
  For now, when end user is creating IPv6-enabled tenant network and
  attaching it to the virtual router, there are two ways to set up
  external infrastructure to put traffic back to the router.  One is
  using DHCPv6 PD[1]. BGP is a new option available in Mitaka.  Both
  require configuration of extra external systems (PD server, BGP
  routers).

  In IPv6 Router Advertisements we have an option called Route
  Information Option[2] to advertise more specific routes from gateway.
  We could easily append a section like next one to advertise tenant
  prefix 2001:db8:1::/64 to public network. And if provider network
  router outside OpenStack will be configured to accept these.  This
  might be considered a lighter weight alternative to PD and BGP for
  announcing tenant networks.  Neighboring routers just need to accept
  and honor the announcement.  Externally accessible addresses would
  still need to be routed to any border routers manually.

  interface qg- {
     AdvDefaultLifetime 0;
     route 2001:db8:1::/64 {
     };
  };

  Cisco accepts it by default AFAIK, linux needs a sysctl
  net.ipv6.conf.*.accept_ra_rt_info_max_plen set to 64.

  Moreover, enabling receiving prefixes in router namespaces allows
  routers communicate by themselves.

  For preventing user from advertising subnets that makes no sense for
  outside infrastructure, Address Scopes[3] mechanism should be used:

  1. Administrator creates an address scope and associate an IPv6 subnet pool 
with it.
  2. Administrator creates Public shared network’s subnet from this subnet pool.
  3. Tenant user creates tenant network from this subnet pool and connect it to 
Public shared network with router
  4. OpenStack advertises prefix to the external interface of the router.

  [1]: 
http://specs.openstack.org/openstack/neutron-specs/specs/kilo/ipv6-prefix-delegation.html
  [2]: https://tools.ietf.org/html/rfc4191
  [3]: https://blueprints.launchpad.net/neutron/+spec/address-scopes

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1530331/+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 1460177] Re: [RFE] Support metadata service with IPv6-only tenant network

[Launchpad Bug Tracker]

[Expired for neutron because there has been no activity for 60 days.]

** Changed in: neutron
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1460177

Title:
  [RFE] Support metadata service with IPv6-only tenant network

Status in neutron:
  Expired

Bug description:
  EC2 metatdata service is supported by nova metadata service that is
  running in the management network. Cloud-init running in the instance
  normally accesses the service at 169.254.169.254. Cloud-init can be
  configured with metadata_urls other than the default
  http://169.254.169.254 to access the service. But such configuration
  is not currently supported by openstack.  In order for the instance to
  access the nova metadata service, neutron provides proxy service that
  terminates http://169.254.169.254 and forwards the request to the nova
  metadata service, and responds back to the instance. Apparently, this
  works only when IPv4 is available in the tenant network. For an
  IPv6-only tenant work, to continue the support of this service, the
  instance has to access it at an IPv6 address. This requires
  enhancement in Neutron to support it.

  A few options have been discussed so far:
     -- define a well-known ipv6 link-local address to access the metadata 
service.
     -- enhance IPv6 RA to advertise the metadata service endpoint to 
instances. This would require standards work and enhance cloud-init to support 
it.
     -- define a well-known name for the metadata service and configure 
metadata_urls to use the name.  The name will be resolved to a datacenter 
specific IP address. The corresponding DNS record should be pre-provisioned in 
the datacenter DNS server for the instance to resolve the name.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1460177/+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 1596829] Re: String interpolation should be delayed at logging calls

[haobing1]

** Also affects: swift
   Importance: Undecided
   Status: New

** Changed in: swift
 Assignee: (unassigned) => haobing1 (haobing1)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1596829

Title:
  String interpolation should be delayed at logging calls

Status in Ceilometer:
  New
Status in Cinder:
  New
Status in Glance:
  New
Status in glance_store:
  New
Status in heat:
  New
Status in Ironic:
  New
Status in OpenStack Identity (keystone):
  New
Status in neutron:
  In Progress
Status in OpenStack Compute (nova):
  In Progress
Status in os-brick:
  New
Status in python-cinderclient:
  New
Status in python-glanceclient:
  New
Status in OpenStack Object Storage (swift):
  New

Bug description:
  String interpolation should be delayed to be handled by the logging
  code, rather than being done at the point of the logging call.

  Wrong: LOG.debug('Example: %s' % 'bad')
  Right: LOG.debug('Example: %s', 'good')

  See the following guideline.

  * http://docs.openstack.org/developer/oslo.i18n/guidelines.html
  #adding-variables-to-log-messages

  The rule for it should be added to hacking checks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1596829/+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 1602080] [NEW] ovs agent doesn't handle security group errors properly

[IWAMOTO Toshihiro]

Public bug reported:

While I was testing my fullstack sg patch, I found ovs_neutron_agent.py
is missing exception handling of setup_port_filters.  See the attached
log for details.

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: ovs sg-fw

** Attachment added: "ovs agent log excerpt"
   https://bugs.launchpad.net/bugs/1602080/+attachment/4699076/+files/a2.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/1602080

Title:
  ovs agent doesn't handle security group errors properly

Status in neutron:
  New

Bug description:
  While I was testing my fullstack sg patch, I found
  ovs_neutron_agent.py is missing exception handling of
  setup_port_filters.  See the attached log for details.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1602080/+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 1602081] [NEW] Use oslo.context's policy dict

[Jamie Lennox]

Public bug reported:

This is a cross project goal to standardize the values available to
policy writers and to improve the basic oslo.context object. It is part
of the follow up work to bug #1577996 and bug #968696.

There has been an ongoing problem for how we define the 'admin' role.
Because tokens are project scoped having the 'admin' role on any project
granted you the 'admin' role on all of OpenStack. As a solution to this
keystone defined an is_admin_project field so that keystone defines a
single project that your token must be scoped to to perform admin
operations. This has been implemented.

The next phase of this is to make all the projects understand the X-Is-
Admin-Project header from keystonemiddleware and pass it to oslo_policy.
However this pattern of keystone changes something and then goes to
every project to fix it has been repeated a number of times now and we
would like to make it much more automatic.

Ongoing work has enhanced the base oslo.context object to include both
the load_from_environ and to_policy_values methods. The
load_from_environ classmethod takes an environment dict with all the
standard auth_token and oslo middleware headers and loads them into
their standard place on the context object.

The to_policy_values() then creates a standard credentials dictionary
with all the information that should be required to enforce policy from
the context. The combination of these two methods means in future when
authentication information needs to be passed to policy it can be
handled entirely by oslo.context and does not require changes in each
individual service.

Note that in future a similar pattern will hopefully be employed to
simplify passing authentication information over RPC to solve the
timeout issues. This is a prerequisite for that work.

There are a few common problems in services that are required to make
this work:

1. Most service context.__init__ functions take and discard **kwargs.
This is so if the context.from_dict receives arguments it doesn't know
how to handle (possibly because new things have been added to the base
to_dict) it ignores them. Unfortunately to make the load_from_environ
method work we need to pass parameters to __init__ that are handled by
the base class.

To make this work we simply have to do a better job of using from_dict.
Instead of passing everything to __init__ and ignoring what we don't
know we have from_dict extract only the parameters that context knows
how to use and call __init__ with those.

2. The parameters passed to the base context.__init__ are old. Typically
they are user and tenant where most services expect user_id and
project_id. There is ongoing work to improve this in oslo.context but
for now we have to ensure that the subclass correctly sets and uses the
right variable names.

3. Some services provide additional information to the policy
enforcement method. To continue to make this function we will simply
override the to_policy_values method in the subclasses.

** Affects: cinder
 Importance: Undecided
 Assignee: Jamie Lennox (jamielennox)
 Status: In Progress

** Affects: glance
 Importance: Undecided
 Status: New

** Affects: heat
 Importance: Undecided
 Assignee: Jamie Lennox (jamielennox)
 Status: In Progress

** Affects: neutron
 Importance: Undecided
 Status: New

** Affects: nova
 Importance: Undecided
 Status: New

** Also affects: glance
   Importance: Undecided
   Status: New

** Also affects: nova
   Importance: Undecided
   Status: New

** Also affects: cinder
   Importance: Undecided
   Status: New

** Also affects: heat
   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/1602081

Title:
  Use oslo.context's policy dict

Status in Cinder:
  In Progress
Status in Glance:
  New
Status in heat:
  In Progress
Status in neutron:
  New
Status in OpenStack Compute (nova):
  New

Bug description:
  This is a cross project goal to standardize the values available to
  policy writers and to improve the basic oslo.context object. It is
  part of the follow up work to bug #1577996 and bug #968696.

  There has been an ongoing problem for how we define the 'admin' role.
  Because tokens are project scoped having the 'admin' role on any
  project granted you the 'admin' role on all of OpenStack. As a
  solution to this keystone defined an is_admin_project field so that
  keystone defines a single project that your token must be scoped to to
  perform admin operations. This has been implemented.

  The next phase of this is to make all the projects understand the X
  -Is-Admin-Project header from keystonemiddleware and pass it to
  oslo_policy. However this pattern of keystone changes something and
  then goes to every project to fix it has been repeated a number of
  times now and we would like to 

[Yahoo-eng-team] [Bug 1602069] Re: Now Host Aggregates can not change 'Availability Zone' to null

[zhurong]

** Changed in: horizon
   Status: New => Invalid

-- 
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/1602069

Title:
  Now Host Aggregates can not change 'Availability Zone' to null

Status in OpenStack Dashboard (Horizon):
  Invalid

Bug description:
  Reproduce:
  create a aggregate with a name, then update this aggregate, delete the 
'Availability Zone' name, update it, but the az name not change. can not update 
this aggregate 'Availability Zone' name to null.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1602069/+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 1586268] Re: Unit test: self.assertNotEqual in unit.test_base.BaseTest.test_eq does not work in PY2

[OpenStack Infra]

Reviewed:  https://review.openstack.org/337033
Committed: 
https://git.openstack.org/cgit/openstack/python-ceilometerclient/commit/?id=f97de95a638347993545686ac9c225d831838340
Submitter: Jenkins
Branch:master

commit f97de95a638347993545686ac9c225d831838340
Author: yuyafei 
Date:   Mon Jul 4 16:23:12 2016 +0800

base.Resource not define __ne__() built-in function

Class base.Resource defines __eq__() built-in function, but does
not define __ne__() built-in function, so self.assertEqual works
but self.assertNotEqual does not work at all in this test case in
python2. This patch fixes it by defining __eq__() built-in function
of class base.Resource. Also fixes spelling errors:resoruces.

Change-Id: I8a4e09e277a14a16105feab81ba8d07ceee5b47f
Closes-Bug: #1586268


** Changed in: python-ceilometerclient
   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/1586268

Title:
  Unit test: self.assertNotEqual in  unit.test_base.BaseTest.test_eq
  does not work in PY2

Status in Ceilometer:
  New
Status in daisycloud-core:
  New
Status in heat:
  New
Status in OpenStack Dashboard (Horizon):
  New
Status in keystonemiddleware:
  New
Status in neutron:
  New
Status in OpenStack Compute (nova):
  In Progress
Status in python-barbicanclient:
  New
Status in python-ceilometerclient:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-congressclient:
  In Progress
Status in python-glanceclient:
  In Progress
Status in python-heatclient:
  Fix Released
Status in python-keystoneclient:
  In Progress
Status in python-manilaclient:
  New
Status in python-muranoclient:
  Fix Released
Status in python-novaclient:
  Fix Released
Status in python-smaugclient:
  In Progress
Status in python-swiftclient:
  New
Status in python-troveclient:
  In Progress
Status in OpenStack Object Storage (swift):
  New
Status in tempest:
  New

Bug description:
  Version: master(20160527)

  In case cinderclient.tests.unit.test_base.BaseTest.test_eq 
self.assertNotEqual does not work.
  Class base.Resource defines __eq__() built-in function, but does not define 
__ne__() built-in function, so self.assertEqual works but self.assertNotEqual 
does not work at all in this test case.

  steps:
  1 Clone code of python-cinderclient from master.
  2 Modify the case of unit test: cinderclient/tests/unit/test_base.py
    line50--line62.
  def test_eq(self):
  # Two resources with same ID: never equal if their info is not equal
  r1 = base.Resource(None, {'id': 1, 'name': 'hi'})
  r2 = base.Resource(None, {'id': 1, 'name': 'hello'})
  self.assertNotEqual(r1, r2)

  # Two resources with same ID: equal if their info is equal
  r1 = base.Resource(None, {'id': 1, 'name': 'hello'})
  r2 = base.Resource(None, {'id': 1, 'name': 'hello'})
  # self.assertEqual(r1, r2)
  self.assertNotEqual(r1, r2)

  # Two resoruces of different types: never equal
  r1 = base.Resource(None, {'id': 1})
  r2 = volumes.Volume(None, {'id': 1})
  self.assertNotEqual(r1, r2)

  # Two resources with no ID: equal if their info is equal
  r1 = base.Resource(None, {'name': 'joe', 'age': 12})
  r2 = base.Resource(None, {'name': 'joe', 'age': 12})
  # self.assertEqual(r1, r2)
  self.assertNotEqual(r1, r2)

     Modify self.assertEqual(r1, r2) to self.assertNotEqual(r1, r2).

  3 Run unit test, and return success.

  After that, I make a test:

  class Resource(object):
  def __init__(self, person):
  self.person = person

  def __eq__(self, other):
  return self.person == other.person

  r1 = Resource("test")
  r2 = Resource("test")
  r3 = Resource("test_r3")
  r4 = Resource("test_r4")

  print r1 != r2
  print r1 == r2
  print r3 != r4
  print r3 == r4

  The result is :
  True
  True
  True
  False

  Whether r1 is precisely the same to r2 or not, self.assertNotEqual(r1,
  r2) return true.So I think self.assertNotEqual doesn't work at all in
  python2 and  should be modified.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1586268/+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 1602069] [NEW] Now Host Aggregates can not change 'Availability Zone' to null

[zhurong]

Public bug reported:

Reproduce:
create a aggregate with a name, then update this aggregate, delete the 
'Availability Zone' name, update it, but the az name not change. can not update 
this aggregate 'Availability Zone' name to null.

** Affects: horizon
 Importance: Undecided
 Assignee: zhurong (zhu-rong)
 Status: Invalid

** Changed in: horizon
 Assignee: (unassigned) => zhurong (zhu-rong)

-- 
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/1602069

Title:
  Now Host Aggregates can not change 'Availability Zone' to null

Status in OpenStack Dashboard (Horizon):
  Invalid

Bug description:
  Reproduce:
  create a aggregate with a name, then update this aggregate, delete the 
'Availability Zone' name, update it, but the az name not change. can not update 
this aggregate 'Availability Zone' name to null.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1602069/+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 1602057] Re: Error updating resources for some node

[shiliang]

** Project changed: fuel-plugin-contrail => nova

** Changed in: nova
   Status: New => In Progress

-- 
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/1602057

Title:
  Error updating resources for some node

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  2016-07-12 09:54:36.021 10056 ERROR nova.compute.manager 
[req-d5d5d486-b488-4429-bbb5-24c9f19ff2c0 - - - - -] Error updating resources 
for node controller.
  2016-07-12 09:54:36.021 10056 ERROR nova.compute.manager Traceback (most 
recent call last):
  2016-07-12 09:54:36.021 10056 ERROR nova.compute.manager   File 
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 6726, in 
update_available_resource
  2016-07-12 09:54:36.021 10056 ERROR nova.compute.manager 
rt.update_available_resource(context)
  2016-07-12 09:54:36.021 10056 ERROR nova.compute.manager   File 
"/usr/lib/python2.7/site-packages/nova/compute/resource_tracker.py", line 500, 
in update_available_resource
  2016-07-12 09:54:36.021 10056 ERROR nova.compute.manager resources = 
self.driver.get_available_resource(self.nodename)
  2016-07-12 09:54:36.021 10056 ERROR nova.compute.manager   File 
"/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 5728, in 
get_available_resource
  2016-07-12 09:54:36.021 10056 ERROR nova.compute.manager 
disk_over_committed = self._get_disk_over_committed_size_total()
  2016-07-12 09:54:36.021 10056 ERROR nova.compute.manager   File 
"/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 7397, in 
_get_disk_over_committed_size_total
  2016-07-12 09:54:36.021 10056 ERROR nova.compute.manager 
local_instances[guest.uuid], bdms[guest.uuid])
  2016-07-12 09:54:36.021 10056 ERROR nova.compute.manager KeyError: 
'0a5c5743-9555-4dfd-b26e-198449ebeee5'
  2016-07-12 09:54:36.021 10056 ERROR nova.compute.manager

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1602057/+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 1602057] [NEW] Error updating resources for some node

[Launchpad Bug Tracker]

You have been subscribed to a public bug:

2016-07-12 09:54:36.021 10056 ERROR nova.compute.manager 
[req-d5d5d486-b488-4429-bbb5-24c9f19ff2c0 - - - - -] Error updating resources 
for node controller.
2016-07-12 09:54:36.021 10056 ERROR nova.compute.manager Traceback (most recent 
call last):
2016-07-12 09:54:36.021 10056 ERROR nova.compute.manager   File 
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 6726, in 
update_available_resource
2016-07-12 09:54:36.021 10056 ERROR nova.compute.manager 
rt.update_available_resource(context)
2016-07-12 09:54:36.021 10056 ERROR nova.compute.manager   File 
"/usr/lib/python2.7/site-packages/nova/compute/resource_tracker.py", line 500, 
in update_available_resource
2016-07-12 09:54:36.021 10056 ERROR nova.compute.manager resources = 
self.driver.get_available_resource(self.nodename)
2016-07-12 09:54:36.021 10056 ERROR nova.compute.manager   File 
"/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 5728, in 
get_available_resource
2016-07-12 09:54:36.021 10056 ERROR nova.compute.manager 
disk_over_committed = self._get_disk_over_committed_size_total()
2016-07-12 09:54:36.021 10056 ERROR nova.compute.manager   File 
"/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 7397, in 
_get_disk_over_committed_size_total
2016-07-12 09:54:36.021 10056 ERROR nova.compute.manager 
local_instances[guest.uuid], bdms[guest.uuid])
2016-07-12 09:54:36.021 10056 ERROR nova.compute.manager KeyError: 
'0a5c5743-9555-4dfd-b26e-198449ebeee5'
2016-07-12 09:54:36.021 10056 ERROR nova.compute.manager

** Affects: nova
 Importance: Undecided
 Assignee: shiliang (shiliang)
 Status: New

-- 
Error updating resources for some node
https://bugs.launchpad.net/bugs/1602057
You received this bug notification because you are a member of Yahoo! 
Engineering Team, which is subscribed to OpenStack Compute (nova).

-- 
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 1280522] Re: Replace assertEqual(None, *) with assertIsNone in tests

[YaoZheng_ZTE]

** Also affects: quark
   Importance: Undecided
   Status: New

** Changed in: quark
 Assignee: (unassigned) => YaoZheng_ZTE (zheng-yao1)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to anvil.
https://bugs.launchpad.net/bugs/1280522

Title:
  Replace assertEqual(None, *) with assertIsNone in tests

Status in Anchor:
  Fix Released
Status in anvil:
  New
Status in bifrost:
  Fix Released
Status in Blazar:
  In Progress
Status in Ceilometer:
  New
Status in Cinder:
  Fix Released
Status in congress:
  Fix Released
Status in Designate:
  Fix Released
Status in dox:
  New
Status in DragonFlow:
  New
Status in Freezer:
  New
Status in Glance:
  Fix Released
Status in glance_store:
  Fix Released
Status in heat:
  Fix Released
Status in heat-cfntools:
  Fix Released
Status in Heat Translator:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-python-agent:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in keystoneauth:
  Fix Released
Status in kolla-mesos:
  Fix Released
Status in Manila:
  Fix Released
Status in networking-brocade:
  New
Status in networking-cisco:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in octavia:
  Fix Released
Status in ooi:
  Fix Released
Status in os-brick:
  In Progress
Status in os-client-config:
  Fix Released
Status in oslo.messaging:
  New
Status in python-barbicanclient:
  Fix Released
Status in python-ceilometerclient:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-congressclient:
  Fix Released
Status in python-cueclient:
  Fix Released
Status in python-designateclient:
  Fix Released
Status in python-glanceclient:
  Fix Released
Status in python-heatclient:
  Fix Released
Status in python-ironicclient:
  Fix Released
Status in python-manilaclient:
  Fix Released
Status in python-neutronclient:
  Fix Released
Status in python-openstackclient:
  Fix Released
Status in OpenStack SDK:
  Fix Released
Status in python-swiftclient:
  Fix Released
Status in python-troveclient:
  Fix Released
Status in Python client library for Zaqar:
  Fix Released
Status in Quark: Money Reinvented:
  New
Status in Sahara:
  Fix Released
Status in OpenStack Search (Searchlight):
  New
Status in Solum:
  Fix Released
Status in Stackalytics:
  Fix Released
Status in OpenStack Object Storage (swift):
  New
Status in taskflow:
  New
Status in tempest:
  Fix Released
Status in OpenStack DBaaS (Trove):
  Fix Released
Status in tuskar:
  Fix Released
Status in watcher:
  Fix Released
Status in zaqar:
  Fix Released
Status in designate package in Ubuntu:
  Fix Released
Status in python-tuskarclient package in Ubuntu:
  Fix Committed

Bug description:
  Replace assertEqual(None, *) with assertIsNone in tests to have
  more clear messages in case of failure.

To manage notifications about this bug go to:
https://bugs.launchpad.net/anchor/+bug/1280522/+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 1280522] Re: Replace assertEqual(None, *) with assertIsNone in tests

[haobing1]

** Also affects: ceilometer
   Importance: Undecided
   Status: New

** Changed in: ceilometer
 Assignee: (unassigned) => haobing1 (haobing1)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to anvil.
https://bugs.launchpad.net/bugs/1280522

Title:
  Replace assertEqual(None, *) with assertIsNone in tests

Status in Anchor:
  Fix Released
Status in anvil:
  New
Status in bifrost:
  Fix Released
Status in Blazar:
  In Progress
Status in Ceilometer:
  New
Status in Cinder:
  Fix Released
Status in congress:
  Fix Released
Status in Designate:
  Fix Released
Status in dox:
  New
Status in DragonFlow:
  New
Status in Freezer:
  New
Status in Glance:
  Fix Released
Status in glance_store:
  Fix Released
Status in heat:
  Fix Released
Status in heat-cfntools:
  Fix Released
Status in Heat Translator:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-python-agent:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in keystoneauth:
  Fix Released
Status in kolla-mesos:
  Fix Released
Status in Manila:
  Fix Released
Status in networking-brocade:
  New
Status in networking-cisco:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in octavia:
  Fix Released
Status in ooi:
  Fix Released
Status in os-brick:
  In Progress
Status in os-client-config:
  Fix Released
Status in oslo.messaging:
  New
Status in python-barbicanclient:
  Fix Released
Status in python-ceilometerclient:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-congressclient:
  Fix Released
Status in python-cueclient:
  Fix Released
Status in python-designateclient:
  Fix Released
Status in python-glanceclient:
  Fix Released
Status in python-heatclient:
  Fix Released
Status in python-ironicclient:
  Fix Released
Status in python-manilaclient:
  Fix Released
Status in python-neutronclient:
  Fix Released
Status in python-openstackclient:
  Fix Released
Status in OpenStack SDK:
  Fix Released
Status in python-swiftclient:
  Fix Released
Status in python-troveclient:
  Fix Released
Status in Python client library for Zaqar:
  Fix Released
Status in Quark: Money Reinvented:
  New
Status in Sahara:
  Fix Released
Status in OpenStack Search (Searchlight):
  New
Status in Solum:
  Fix Released
Status in Stackalytics:
  Fix Released
Status in OpenStack Object Storage (swift):
  New
Status in taskflow:
  New
Status in tempest:
  Fix Released
Status in OpenStack DBaaS (Trove):
  Fix Released
Status in tuskar:
  Fix Released
Status in watcher:
  Fix Released
Status in zaqar:
  Fix Released
Status in designate package in Ubuntu:
  Fix Released
Status in python-tuskarclient package in Ubuntu:
  Fix Committed

Bug description:
  Replace assertEqual(None, *) with assertIsNone in tests to have
  more clear messages in case of failure.

To manage notifications about this bug go to:
https://bugs.launchpad.net/anchor/+bug/1280522/+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 1280522] Re: Replace assertEqual(None, *) with assertIsNone in tests

[YaoZheng_ZTE]

** Also affects: anvil
   Importance: Undecided
   Status: New

** Changed in: anvil
 Assignee: (unassigned) => YaoZheng_ZTE (zheng-yao1)

** Also affects: networking-brocade
   Importance: Undecided
   Status: New

** Changed in: networking-brocade
 Assignee: (unassigned) => YaoZheng_ZTE (zheng-yao1)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to anvil.
https://bugs.launchpad.net/bugs/1280522

Title:
  Replace assertEqual(None, *) with assertIsNone in tests

Status in Anchor:
  Fix Released
Status in anvil:
  New
Status in bifrost:
  Fix Released
Status in Blazar:
  In Progress
Status in Ceilometer:
  New
Status in Cinder:
  Fix Released
Status in congress:
  Fix Released
Status in Designate:
  Fix Released
Status in dox:
  New
Status in DragonFlow:
  New
Status in Freezer:
  New
Status in Glance:
  Fix Released
Status in glance_store:
  Fix Released
Status in heat:
  Fix Released
Status in heat-cfntools:
  Fix Released
Status in Heat Translator:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-python-agent:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in keystoneauth:
  Fix Released
Status in kolla-mesos:
  Fix Released
Status in Manila:
  Fix Released
Status in networking-brocade:
  New
Status in networking-cisco:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in octavia:
  Fix Released
Status in ooi:
  Fix Released
Status in os-brick:
  In Progress
Status in os-client-config:
  Fix Released
Status in oslo.messaging:
  New
Status in python-barbicanclient:
  Fix Released
Status in python-ceilometerclient:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-congressclient:
  Fix Released
Status in python-cueclient:
  Fix Released
Status in python-designateclient:
  Fix Released
Status in python-glanceclient:
  Fix Released
Status in python-heatclient:
  Fix Released
Status in python-ironicclient:
  Fix Released
Status in python-manilaclient:
  Fix Released
Status in python-neutronclient:
  Fix Released
Status in python-openstackclient:
  Fix Released
Status in OpenStack SDK:
  Fix Released
Status in python-swiftclient:
  Fix Released
Status in python-troveclient:
  Fix Released
Status in Python client library for Zaqar:
  Fix Released
Status in Quark: Money Reinvented:
  New
Status in Sahara:
  Fix Released
Status in OpenStack Search (Searchlight):
  New
Status in Solum:
  Fix Released
Status in Stackalytics:
  Fix Released
Status in OpenStack Object Storage (swift):
  New
Status in taskflow:
  New
Status in tempest:
  Fix Released
Status in OpenStack DBaaS (Trove):
  Fix Released
Status in tuskar:
  Fix Released
Status in watcher:
  Fix Released
Status in zaqar:
  Fix Released
Status in designate package in Ubuntu:
  Fix Released
Status in python-tuskarclient package in Ubuntu:
  Fix Committed

Bug description:
  Replace assertEqual(None, *) with assertIsNone in tests to have
  more clear messages in case of failure.

To manage notifications about this bug go to:
https://bugs.launchpad.net/anchor/+bug/1280522/+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 1596829] Re: String interpolation should be delayed at logging calls

[weiweigu]

** Also affects: keystone
   Importance: Undecided
   Status: New

** Changed in: keystone
 Assignee: (unassigned) => weiweigu (gu-weiwei)

** Also affects: ironic
   Importance: Undecided
   Status: New

** Changed in: ironic
 Assignee: (unassigned) => weiweigu (gu-weiwei)

** Also affects: heat
   Importance: Undecided
   Status: New

** Changed in: heat
 Assignee: (unassigned) => weiweigu (gu-weiwei)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1596829

Title:
  String interpolation should be delayed at logging calls

Status in Ceilometer:
  New
Status in Cinder:
  New
Status in Glance:
  New
Status in glance_store:
  New
Status in heat:
  New
Status in Ironic:
  New
Status in OpenStack Identity (keystone):
  New
Status in neutron:
  In Progress
Status in OpenStack Compute (nova):
  In Progress
Status in os-brick:
  New
Status in python-cinderclient:
  New
Status in python-glanceclient:
  New

Bug description:
  String interpolation should be delayed to be handled by the logging
  code, rather than being done at the point of the logging call.

  Wrong: LOG.debug('Example: %s' % 'bad')
  Right: LOG.debug('Example: %s', 'good')

  See the following guideline.

  * http://docs.openstack.org/developer/oslo.i18n/guidelines.html
  #adding-variables-to-log-messages

  The rule for it should be added to hacking checks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1596829/+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 1280522] Re: Replace assertEqual(None, *) with assertIsNone in tests

[weiweigu]

** Also affects: taskflow
   Importance: Undecided
   Status: New

** Changed in: taskflow
 Assignee: (unassigned) => weiweigu (gu-weiwei)

** Also affects: oslo.messaging
   Importance: Undecided
   Status: New

** Changed in: oslo.messaging
 Assignee: (unassigned) => weiweigu (gu-weiwei)

-- 
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/1280522

Title:
  Replace assertEqual(None, *) with assertIsNone in tests

Status in Anchor:
  Fix Released
Status in anvil:
  New
Status in bifrost:
  Fix Released
Status in Blazar:
  In Progress
Status in Cinder:
  Fix Released
Status in congress:
  Fix Released
Status in Designate:
  Fix Released
Status in dox:
  New
Status in DragonFlow:
  New
Status in Freezer:
  New
Status in Glance:
  Fix Released
Status in glance_store:
  Fix Released
Status in heat:
  Fix Released
Status in heat-cfntools:
  Fix Released
Status in Heat Translator:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-python-agent:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in keystoneauth:
  Fix Released
Status in kolla-mesos:
  Fix Released
Status in Manila:
  Fix Released
Status in networking-cisco:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in octavia:
  Fix Released
Status in ooi:
  Fix Released
Status in os-brick:
  In Progress
Status in os-client-config:
  Fix Released
Status in oslo.messaging:
  New
Status in python-barbicanclient:
  Fix Released
Status in python-ceilometerclient:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-congressclient:
  Fix Released
Status in python-cueclient:
  Fix Released
Status in python-designateclient:
  Fix Released
Status in python-glanceclient:
  Fix Released
Status in python-heatclient:
  Fix Released
Status in python-ironicclient:
  Fix Released
Status in python-manilaclient:
  Fix Released
Status in python-neutronclient:
  Fix Released
Status in python-openstackclient:
  Fix Released
Status in OpenStack SDK:
  Fix Released
Status in python-swiftclient:
  Fix Released
Status in python-troveclient:
  Fix Released
Status in Python client library for Zaqar:
  Fix Released
Status in Sahara:
  Fix Released
Status in OpenStack Search (Searchlight):
  New
Status in Solum:
  Fix Released
Status in Stackalytics:
  Fix Released
Status in OpenStack Object Storage (swift):
  New
Status in taskflow:
  New
Status in tempest:
  Fix Released
Status in OpenStack DBaaS (Trove):
  Fix Released
Status in tuskar:
  Fix Released
Status in watcher:
  Fix Released
Status in zaqar:
  Fix Released
Status in designate package in Ubuntu:
  Fix Released
Status in python-tuskarclient package in Ubuntu:
  Fix Committed

Bug description:
  Replace assertEqual(None, *) with assertIsNone in tests to have
  more clear messages in case of failure.

To manage notifications about this bug go to:
https://bugs.launchpad.net/anchor/+bug/1280522/+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 1280522] Re: Replace assertEqual(None, *) with assertIsNone in tests

[YaoZheng_ZTE]

** Also affects: freezer
   Importance: Undecided
   Status: New

** Changed in: freezer
 Assignee: (unassigned) => YaoZheng_ZTE (zheng-yao1)

** Also affects: dragonflow
   Importance: Undecided
   Status: New

** Changed in: dragonflow
 Assignee: (unassigned) => YaoZheng_ZTE (zheng-yao1)

-- 
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/1280522

Title:
  Replace assertEqual(None, *) with assertIsNone in tests

Status in Anchor:
  Fix Released
Status in bifrost:
  Fix Released
Status in Blazar:
  In Progress
Status in Cinder:
  Fix Released
Status in congress:
  Fix Released
Status in Designate:
  Fix Released
Status in dox:
  New
Status in DragonFlow:
  New
Status in Freezer:
  New
Status in Glance:
  Fix Released
Status in glance_store:
  Fix Released
Status in heat:
  Fix Released
Status in heat-cfntools:
  Fix Released
Status in Heat Translator:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-python-agent:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in keystoneauth:
  Fix Released
Status in kolla-mesos:
  Fix Released
Status in Manila:
  Fix Released
Status in networking-cisco:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in octavia:
  Fix Released
Status in ooi:
  Fix Released
Status in os-brick:
  New
Status in os-client-config:
  Fix Released
Status in python-barbicanclient:
  Fix Released
Status in python-ceilometerclient:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-congressclient:
  Fix Released
Status in python-cueclient:
  Fix Released
Status in python-designateclient:
  Fix Released
Status in python-glanceclient:
  Fix Released
Status in python-heatclient:
  Fix Released
Status in python-ironicclient:
  Fix Released
Status in python-manilaclient:
  Fix Released
Status in python-neutronclient:
  Fix Released
Status in python-openstackclient:
  Fix Released
Status in OpenStack SDK:
  Fix Released
Status in python-swiftclient:
  Fix Released
Status in python-troveclient:
  Fix Released
Status in Python client library for Zaqar:
  Fix Released
Status in Sahara:
  Fix Released
Status in OpenStack Search (Searchlight):
  New
Status in Solum:
  Fix Released
Status in Stackalytics:
  Fix Released
Status in OpenStack Object Storage (swift):
  New
Status in taskflow:
  New
Status in tempest:
  Fix Released
Status in OpenStack DBaaS (Trove):
  Fix Released
Status in tuskar:
  Fix Released
Status in watcher:
  Fix Released
Status in zaqar:
  Fix Released
Status in designate package in Ubuntu:
  Fix Released
Status in python-tuskarclient package in Ubuntu:
  Fix Committed

Bug description:
  Replace assertEqual(None, *) with assertIsNone in tests to have
  more clear messages in case of failure.

To manage notifications about this bug go to:
https://bugs.launchpad.net/anchor/+bug/1280522/+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 1596829] Re: String interpolation should be delayed at logging calls

[haobing1]

** Also affects: python-cinderclient
   Importance: Undecided
   Status: New

** Changed in: python-cinderclient
 Assignee: (unassigned) => haobing1 (haobing1)

** Also affects: python-glanceclient
   Importance: Undecided
   Status: New

** Changed in: python-glanceclient
 Assignee: (unassigned) => haobing1 (haobing1)

** Also affects: glance-store
   Importance: Undecided
   Status: New

** Changed in: glance-store
 Assignee: (unassigned) => haobing1 (haobing1)

** Also affects: ceilometer
   Importance: Undecided
   Status: New

** Changed in: ceilometer
 Assignee: (unassigned) => haobing1 (haobing1)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1596829

Title:
  String interpolation should be delayed at logging calls

Status in Ceilometer:
  New
Status in Cinder:
  New
Status in Glance:
  New
Status in glance_store:
  New
Status in neutron:
  In Progress
Status in OpenStack Compute (nova):
  In Progress
Status in os-brick:
  New
Status in python-cinderclient:
  New
Status in python-glanceclient:
  New

Bug description:
  String interpolation should be delayed to be handled by the logging
  code, rather than being done at the point of the logging call.

  Wrong: LOG.debug('Example: %s' % 'bad')
  Right: LOG.debug('Example: %s', 'good')

  See the following guideline.

  * http://docs.openstack.org/developer/oslo.i18n/guidelines.html
  #adding-variables-to-log-messages

  The rule for it should be added to hacking checks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1596829/+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 1596829] Re: String interpolation should be delayed at logging calls

[weiweigu]

** Also affects: os-brick
   Importance: Undecided
   Status: New

** Changed in: os-brick
 Assignee: (unassigned) => weiweigu (gu-weiwei)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1596829

Title:
  String interpolation should be delayed at logging calls

Status in Cinder:
  New
Status in Glance:
  New
Status in glance_store:
  New
Status in neutron:
  In Progress
Status in OpenStack Compute (nova):
  In Progress
Status in os-brick:
  New
Status in python-cinderclient:
  New
Status in python-glanceclient:
  New

Bug description:
  String interpolation should be delayed to be handled by the logging
  code, rather than being done at the point of the logging call.

  Wrong: LOG.debug('Example: %s' % 'bad')
  Right: LOG.debug('Example: %s', 'good')

  See the following guideline.

  * http://docs.openstack.org/developer/oslo.i18n/guidelines.html
  #adding-variables-to-log-messages

  The rule for it should be added to hacking checks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1596829/+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 1280522] Re: Replace assertEqual(None, *) with assertIsNone in tests

[jingtao liang]

** Also affects: swift
   Importance: Undecided
   Status: New

** Changed in: swift
 Assignee: (unassigned) => jingtao liang (liang-jingtao)

-- 
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/1280522

Title:
  Replace assertEqual(None, *) with assertIsNone in tests

Status in Anchor:
  Fix Released
Status in bifrost:
  Fix Released
Status in Blazar:
  In Progress
Status in Cinder:
  Fix Released
Status in congress:
  Fix Released
Status in Designate:
  Fix Released
Status in dox:
  New
Status in Glance:
  Fix Released
Status in glance_store:
  Fix Released
Status in heat:
  Fix Released
Status in heat-cfntools:
  Fix Released
Status in Heat Translator:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-python-agent:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in keystoneauth:
  Fix Released
Status in kolla-mesos:
  Fix Released
Status in Manila:
  Fix Released
Status in networking-cisco:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in octavia:
  Fix Released
Status in ooi:
  Fix Released
Status in os-brick:
  New
Status in os-client-config:
  Fix Released
Status in python-barbicanclient:
  Fix Released
Status in python-ceilometerclient:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-congressclient:
  Fix Released
Status in python-cueclient:
  Fix Released
Status in python-designateclient:
  Fix Released
Status in python-glanceclient:
  Fix Released
Status in python-heatclient:
  Fix Released
Status in python-ironicclient:
  Fix Released
Status in python-manilaclient:
  Fix Released
Status in python-neutronclient:
  Fix Released
Status in python-openstackclient:
  Fix Released
Status in OpenStack SDK:
  Fix Released
Status in python-swiftclient:
  Fix Released
Status in python-troveclient:
  Fix Released
Status in Python client library for Zaqar:
  Fix Released
Status in Sahara:
  Fix Released
Status in OpenStack Search (Searchlight):
  New
Status in Solum:
  Fix Released
Status in Stackalytics:
  Fix Released
Status in OpenStack Object Storage (swift):
  New
Status in tempest:
  Fix Released
Status in OpenStack DBaaS (Trove):
  Fix Released
Status in tuskar:
  Fix Released
Status in watcher:
  Fix Released
Status in zaqar:
  Fix Released
Status in designate package in Ubuntu:
  Fix Released
Status in python-tuskarclient package in Ubuntu:
  Fix Committed

Bug description:
  Replace assertEqual(None, *) with assertIsNone in tests to have
  more clear messages in case of failure.

To manage notifications about this bug go to:
https://bugs.launchpad.net/anchor/+bug/1280522/+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 1600396] Re: AssertionError: 0 == 0 : No IPv4 addresses found on gate-tempest-dsvm-neutron-full

[OpenStack Infra]

Reviewed:  https://review.openstack.org/339873
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=2bf72116701a2c7c02eab4a87f1e87616a0d6f6b
Submitter: Jenkins
Branch:master

commit 2bf72116701a2c7c02eab4a87f1e87616a0d6f6b
Author: Kevin Benton 
Date:   Fri Jul 8 16:42:10 2016 -0700

Check for provisioning blocks before updating port up

There is a race we need to check for where a port is created and
then updated with binding information via another API shortly
afterward that causes the bug referenced in this message.

* The port is created and a DHCP provisioning block is added.
* The DHCP agent finishes setting up the reservation and emits a
  message to clear the block.
* The _port_provisioned callback in ML2 is triggered.
* A port update comes in that binds the port and adds new blocks.
* The _port_provisioned callback now does a get_port and sees
  that the port is bound so it assumes everything is done and
  the port can be marked ACTIVE.
* The port is now ACTIVE before the L2 agent has had a chance to
  do its wiring and the VM boots.
* The L2 agent requests the details and the port flaps back to
  BUILD.
* The L2 agent finishes and clears the provisioning block a second
  time so the port goes back to ACTIVE.

This will randomly cause failures because the VM is booting before the
L2 agent is done and tempest may see the port in the BUILD state after
the agent grabs port details.

The fix is relatively simple. Just check for any new provisioning blocks
added *after* doing a get_port in the _port_provisioned callback to make
sure we don't update to ACTIVE if there are newly added blocks.

Closes-Bug: #1600396
Change-Id: I14f41a5fda0707e8bba064c5cd952553686c30cd


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

Title:
  AssertionError: 0 == 0 : No IPv4 addresses found on gate-tempest-dsvm-
  neutron-full

Status in neutron:
  Fix Released

Bug description:
  
http://logs.openstack.org/60/337060/2/gate/gate-tempest-dsvm-neutron-full/6beb9d6/logs/
  
http://logs.openstack.org/64/336264/3/gate/gate-tempest-dsvm-neutron-full/c8b4462/logs/
  
http://logs.openstack.org/64/336264/3/gate/gate-tempest-dsvm-neutron-full/7768042/logs/
  
http://logs.openstack.org/41/334641/3/gate/gate-tempest-dsvm-neutron-full/8dbdf00/logs/

  For instance:

  Traceback (most recent call last):
File "tempest/test.py", line 106, in wrapper
  return f(self, *func_args, **func_kwargs)
File "tempest/scenario/test_network_advanced_server_ops.py", line 135, in 
test_server_connectivity_pause_unpause
  server, keypair, floating_ip = self._setup_network_and_servers()
File "tempest/scenario/test_network_advanced_server_ops.py", line 68, in 
_setup_network_and_servers
  floating_ip = self.create_floating_ip(server, public_network_id)
File "tempest/scenario/manager.py", line 868, in create_floating_ip
  port_id, ip4 = self._get_server_port_id_and_ip4(thing)
File "tempest/scenario/manager.py", line 847, in _get_server_port_id_and_ip4
  "No IPv4 addresses found in: %s" % ports)
File 
"/opt/stack/new/tempest/.tox/tempest/local/lib/python2.7/site-packages/unittest2/case.py",
 line 845, in assertNotEqual
  raise self.failureException(msg)
  AssertionError: 0 == 0 : No IPv4 addresses found in: [{u'device_owner': 
u'compute:None', u'binding:vif_type': u'ovs', u'status': u'BUILD', u'name': 
u'', u'binding:vif_details': {u'ovs_hybrid_plug': True, u'port_filter': True}, 
u'mac_address': u'fa:16:3e:4b:38:5d', u'updated_at': u'2016-07-05T12:35:22', 
u'binding:host_id': u'ubuntu-trusty-ovh-bhs1-2218654', u'device_id': 
u'd988986e-64bd-45c6-9863-5d56efb0fdf6', u'security_groups': 
[u'9701d305-ee33-4ed7-a598-dfe4829e6862'], u'port_security_enabled': True, 
u'extra_dhcp_opts': [], u'binding:profile': {}, u'description': u'', u'id': 
u'7be0c6ef-a535-400e-8a75-4d747b1fb494', u'admin_state_up': True, u'tenant_id': 
u'6752ff05a55a436f9ed0b38fe0ff37de', u'binding:vnic_type': u'normal', 
u'created_at': u'2016-07-05T12:35:17', u'network_id': 
u'5fee9c7d-2d3c-4281-81d7-e5d9240edf89', u'fixed_ips': [{u'ip_address': 
u'10.100.0.9', u'subnet_id': u'8dc61ef8-39fa-44b3-bed6-7f9b78746c31'}], 
u'allowed_address_pairs': []}]

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1600396/+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 1600725] Re: add groupv3 controller unit test code in master branch

[huyupeng]

ok, i got it. you guys were right, i made a mistake.

i read keystone source code , and found only user test code were written
in file identity/test_controller.py, so i decided to add the group test
code. there was a misunderstand for me.

actually, the v3 test code had been added in test_v3_identity.py.

how could i found the relative unittest code for the src code quickly,
is there some rules ?

** Changed in: keystone
   Status: Incomplete => 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/1600725

Title:
  add groupv3 controller unit test code in master branch

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  add groupv3 controller unit test code in master branch

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1600725/+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 1280522] Re: Replace assertEqual(None, *) with assertIsNone in tests

[yuyafei]

** Also affects: os-brick
   Importance: Undecided
   Status: New

** Changed in: os-brick
 Assignee: (unassigned) => yuyafei (yu-yafei)

-- 
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/1280522

Title:
  Replace assertEqual(None, *) with assertIsNone in tests

Status in Anchor:
  Fix Released
Status in bifrost:
  Fix Released
Status in Blazar:
  In Progress
Status in Cinder:
  Fix Released
Status in congress:
  Fix Released
Status in Designate:
  Fix Released
Status in dox:
  New
Status in Glance:
  Fix Released
Status in glance_store:
  Fix Released
Status in heat:
  Fix Released
Status in heat-cfntools:
  Fix Released
Status in Heat Translator:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-python-agent:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in keystoneauth:
  Fix Released
Status in kolla-mesos:
  Fix Released
Status in Manila:
  Fix Released
Status in networking-cisco:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in octavia:
  Fix Released
Status in ooi:
  Fix Released
Status in os-brick:
  New
Status in os-client-config:
  Fix Released
Status in python-barbicanclient:
  Fix Released
Status in python-ceilometerclient:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-congressclient:
  Fix Released
Status in python-cueclient:
  Fix Released
Status in python-designateclient:
  Fix Released
Status in python-glanceclient:
  Fix Released
Status in python-heatclient:
  Fix Released
Status in python-ironicclient:
  Fix Released
Status in python-manilaclient:
  Fix Released
Status in python-neutronclient:
  Fix Released
Status in python-openstackclient:
  Fix Released
Status in OpenStack SDK:
  Fix Released
Status in python-swiftclient:
  Fix Released
Status in python-troveclient:
  Fix Released
Status in Python client library for Zaqar:
  Fix Released
Status in Sahara:
  Fix Released
Status in OpenStack Search (Searchlight):
  New
Status in Solum:
  Fix Released
Status in Stackalytics:
  Fix Released
Status in tempest:
  Fix Released
Status in OpenStack DBaaS (Trove):
  Fix Released
Status in tuskar:
  Fix Released
Status in watcher:
  Fix Released
Status in zaqar:
  Fix Released
Status in designate package in Ubuntu:
  Fix Released
Status in python-tuskarclient package in Ubuntu:
  Fix Committed

Bug description:
  Replace assertEqual(None, *) with assertIsNone in tests to have
  more clear messages in case of failure.

To manage notifications about this bug go to:
https://bugs.launchpad.net/anchor/+bug/1280522/+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 1280522] Re: Replace assertEqual(None, *) with assertIsNone in tests

[jingtao liang]

** Also affects: searchlight
   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/1280522

Title:
  Replace assertEqual(None, *) with assertIsNone in tests

Status in Anchor:
  Fix Released
Status in bifrost:
  Fix Released
Status in Blazar:
  In Progress
Status in Cinder:
  Fix Released
Status in congress:
  Fix Released
Status in Designate:
  Fix Released
Status in dox:
  New
Status in Glance:
  Fix Released
Status in glance_store:
  Fix Released
Status in heat:
  Fix Released
Status in heat-cfntools:
  Fix Released
Status in Heat Translator:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-python-agent:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in keystoneauth:
  Fix Released
Status in kolla-mesos:
  Fix Released
Status in Manila:
  Fix Released
Status in networking-cisco:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in octavia:
  Fix Released
Status in ooi:
  Fix Released
Status in os-brick:
  New
Status in os-client-config:
  Fix Released
Status in python-barbicanclient:
  Fix Released
Status in python-ceilometerclient:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-congressclient:
  Fix Released
Status in python-cueclient:
  Fix Released
Status in python-designateclient:
  Fix Released
Status in python-glanceclient:
  Fix Released
Status in python-heatclient:
  Fix Released
Status in python-ironicclient:
  Fix Released
Status in python-manilaclient:
  Fix Released
Status in python-neutronclient:
  Fix Released
Status in python-openstackclient:
  Fix Released
Status in OpenStack SDK:
  Fix Released
Status in python-swiftclient:
  Fix Released
Status in python-troveclient:
  Fix Released
Status in Python client library for Zaqar:
  Fix Released
Status in Sahara:
  Fix Released
Status in OpenStack Search (Searchlight):
  New
Status in Solum:
  Fix Released
Status in Stackalytics:
  Fix Released
Status in tempest:
  Fix Released
Status in OpenStack DBaaS (Trove):
  Fix Released
Status in tuskar:
  Fix Released
Status in watcher:
  Fix Released
Status in zaqar:
  Fix Released
Status in designate package in Ubuntu:
  Fix Released
Status in python-tuskarclient package in Ubuntu:
  Fix Committed

Bug description:
  Replace assertEqual(None, *) with assertIsNone in tests to have
  more clear messages in case of failure.

To manage notifications about this bug go to:
https://bugs.launchpad.net/anchor/+bug/1280522/+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 1596829] Re: String interpolation should be delayed at logging calls

[weiweigu]

** Also affects: cinder
   Importance: Undecided
   Status: New

** Changed in: cinder
 Assignee: (unassigned) => weiweigu (gu-weiwei)

** Also affects: glance
   Importance: Undecided
   Status: New

** Changed in: glance
 Assignee: (unassigned) => weiweigu (gu-weiwei)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1596829

Title:
  String interpolation should be delayed at logging calls

Status in Cinder:
  New
Status in Glance:
  New
Status in neutron:
  In Progress
Status in OpenStack Compute (nova):
  In Progress

Bug description:
  String interpolation should be delayed to be handled by the logging
  code, rather than being done at the point of the logging call.

  Wrong: LOG.debug('Example: %s' % 'bad')
  Right: LOG.debug('Example: %s', 'good')

  See the following guideline.

  * http://docs.openstack.org/developer/oslo.i18n/guidelines.html
  #adding-variables-to-log-messages

  The rule for it should be added to hacking checks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1596829/+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 1602044] [NEW] Update server tag return plain text in response body instead of empty

[Ghanshyam Mann]

Public bug reported:

update server tag API (PUT /servers/{server_id}/tags/{tag}) return the
201 and 204 success code if tag is created or already exist
respectively.

But in former case, API return response body with plain text-

'{"code": "201 Created", "message": "\\n\\n\\n", "title":
"Created"}'

This is because it use webob.exc to generate 201. This kind of response
body will break while parsing the data for content type. Also this is
consistent with other nova API.

webob.Response is the right choice to generate 201 without content.

** Affects: nova
 Importance: Undecided
 Assignee: Ghanshyam Mann (ghanshyammann)
 Status: New

** Changed in: nova
 Assignee: (unassigned) => Ghanshyam Mann (ghanshyammann)

-- 
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/1602044

Title:
  Update server tag return plain text in response body instead of empty

Status in OpenStack Compute (nova):
  New

Bug description:
  update server tag API (PUT /servers/{server_id}/tags/{tag}) return the
  201 and 204 success code if tag is created or already exist
  respectively.

  But in former case, API return response body with plain text-

  '{"code": "201 Created", "message": "\\n\\n\\n", "title":
  "Created"}'

  This is because it use webob.exc to generate 201. This kind of
  response body will break while parsing the data for content type. Also
  this is consistent with other nova API.

  webob.Response is the right choice to generate 201 without content.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1602044/+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 1404867] Re: Volume remains in-use status, if instance booted from volume is deleted in error state

[melanie witt]

Fix was reverted again https://review.openstack.org/#/c/340479/

** Changed in: nova
   Status: Fix Released => Confirmed

-- 
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/1404867

Title:
  Volume remains in-use status, if instance booted from volume is
  deleted in error state

Status in OpenStack Compute (nova):
  Confirmed

Bug description:
  If the instance is booted from volume and goes in to error state due to some 
reason.
  Volume from which instance is booted, remains in-use state even the instance 
is deleted.
  IMO, volume should be detached so that it can be used to boot other instance.

  Steps to reproduce:

  1. Log in to Horizon, create a new volume.
  2. Create an Instance using newly created volume.
  3. Verify instance is in active state.
  $ source devstack/openrc demo demo
  $ nova list
  
+--+--+++-+--+
  | ID   | Name | Status | Task State | Power 
State | Networks |
  
+--+--+++-+--+
  | dae3a13b-6aa8-4794-93cd-5ab7bf90f604 | nova | ACTIVE | -  | Running 
| private=10.0.0.3 |
  
+--+--+++-+--+

  Note:
  Use shelve-unshelve api to see the instance goes into error state.
  unshelving volumed back instance does not work and sets instance state to 
error state (ref: https://bugs.launchpad.net/nova/+bug/1404801)

  4. Shelve the instance
  $ nova shelve 

  5. Verify the status is SHELVED_OFFLOADED.
  $ nova list
  
+--+--+---++-+--+
  | ID   | Name | Status| Task 
State | Power State | Networks |
  
+--+--+---++-+--+
  | dae3a13b-6aa8-4794-93cd-5ab7bf90f604 | nova | SHELVED_OFFLOADED | - 
 | Shutdown| private=10.0.0.3 |
  
+--+--+---++-+--+

  6. Unshelve the instance.
  $ nova unshelve 

  5. Verify the instance is in Error state.
  $ nova list
  
+--+--+---++-+--+
  | ID   | Name | Status| Task 
State | Power State | Networks |
  
+--+--+---++-+--+
  | dae3a13b-6aa8-4794-93cd-5ab7bf90f604 | nova | Error | 
unshelving | Spawning| private=10.0.0.3 |
  
+--+--+---++-+--+

  6. Delete the instance using Horizon.

  7. Verify that volume still in in-use state
  $ cinder list
  
+--++--+--+-+--+--+
  |  ID  | Status | Name | Size | Volume Type | 
Bootable | Attached to  |
  
+--++--+--+-+--+--+
  | 4aeefd25-10aa-42c2-9a2d-1c89a95b4d4f | in-use | test |  1   | lvmdriver-1 | 
  true   | 8f7bdc24-1891-4bbb-8f0c-732b9cbecae7 |
  
+--++--+--+-+--+--+

  8. In Horizon, volume "Attached To" information is displayed as
  "Attached to None on /dev/vda".

  9. User is not able to delete this volume, or attached it to another
  instance as it is still in use.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1404867/+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 1600031] Re: libvirt: KeyError in _get_disk_over_committed_size_total

[OpenStack Infra]

Reviewed:  https://review.openstack.org/340479
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=c1a83a3fb8b7a2ad6bd0d0bafb4a38719cf487ae
Submitter: Jenkins
Branch:master

commit c1a83a3fb8b7a2ad6bd0d0bafb4a38719cf487ae
Author: Matt Riedemann 
Date:   Mon Jul 11 17:14:16 2016 +

Revert "Detach volume after deleting instance with no host"

This reverts commit 5ce74fa06c0e7a70fdc927b2c1f364af83f7de1d.

We think this is causing a race and the postgres job to fail
since it's erroneously doing local deletes and not cleaning
up from the computes. We're not totally sure why it would
only impact the postgres job though, but the original change
failed the job and was rechecked, and the time it was merged
coincides with when the postgres job started spiking with
failures.

Related-Bug: #165
Closes-Bug: #1600031

Change-Id: I0ed184b579b8a8d861e4d2a7c317bf0bc0623d50


** Changed in: nova
   Status: In Progress => Fix Released

-- 
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/1600031

Title:
  libvirt: KeyError in _get_disk_over_committed_size_total

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  Seen here:

  http://logs.openstack.org/21/299621/7/gate/gate-tempest-dsvm-postgres-
  full/c182c88/logs/screen-n-cpu.txt.gz#_2016-07-07_21_08_11_773

  2016-07-07 21:08:11.773 14821 ERROR nova.compute.manager 
[req-1bfb9ba6-a2de-417e-9ad7-f72053ff9d96 - -] Error updating resources for 
node ubuntu-trusty-osic-cloud1-2340260.
  2016-07-07 21:08:11.773 14821 ERROR nova.compute.manager Traceback (most 
recent call last):
  2016-07-07 21:08:11.773 14821 ERROR nova.compute.manager   File 
"/opt/stack/new/nova/nova/compute/manager.py", line 6338, in 
update_available_resource_for_node
  2016-07-07 21:08:11.773 14821 ERROR nova.compute.manager 
rt.update_available_resource(context)
  2016-07-07 21:08:11.773 14821 ERROR nova.compute.manager   File 
"/opt/stack/new/nova/nova/compute/resource_tracker.py", line 502, in 
update_available_resource
  2016-07-07 21:08:11.773 14821 ERROR nova.compute.manager resources = 
self.driver.get_available_resource(self.nodename)
  2016-07-07 21:08:11.773 14821 ERROR nova.compute.manager   File 
"/opt/stack/new/nova/nova/virt/libvirt/driver.py", line 5349, in 
get_available_resource
  2016-07-07 21:08:11.773 14821 ERROR nova.compute.manager 
disk_over_committed = self._get_disk_over_committed_size_total()
  2016-07-07 21:08:11.773 14821 ERROR nova.compute.manager   File 
"/opt/stack/new/nova/nova/virt/libvirt/driver.py", line 6898, in 
_get_disk_over_committed_size_total
  2016-07-07 21:08:11.773 14821 ERROR nova.compute.manager 
local_instances[guest.uuid], bdms[guest.uuid])
  2016-07-07 21:08:11.773 14821 ERROR nova.compute.manager KeyError: 
'6b454071-c139-490d-96af-df701521330f'
  2016-07-07 21:08:11.773 14821 ERROR nova.compute.manager 

  It's coming from a DeleteServersAdminTestJSON test. There are two
  tests, I'm not sure which it is.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1600031/+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 1602023] [NEW] Incorrect cellid in NUMA memnode

[Rafael Folco]

Public bug reported:

Description
===

Nova generating wrong cellid for numa memnode.

Some systems number nodeset for the NUMA topology in non-sequential way,
as follows:

node   0   1  16  17


Steps to reproduce
==
Create a flavor w/ hw:numa_nodes=4 (hw:cpu_policy unset)

Spawn an instance across multiple nodes

Check nodeset in the instance XML


Expected result
===

Correct cellid:










Actual result
=


Wrong cellid:










Environment
===

Ubuntu Xenial 16.10, OpenStack Mitaka release, Libvirt 1.3.1

Note: This issue has been found / tested on Ubuntu KVM on Power (ppc64le
arch), however, it *may* affect other architectures.

** Affects: nova
 Importance: Undecided
 Assignee: Rafael Folco (rafaelfolco)
 Status: In Progress

-- 
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/1602023

Title:
  Incorrect cellid in NUMA memnode

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  Description
  ===

  Nova generating wrong cellid for numa memnode.

  Some systems number nodeset for the NUMA topology in non-sequential
  way, as follows:

  node   0   1  16  17



  Steps to reproduce
  ==
  Create a flavor w/ hw:numa_nodes=4 (hw:cpu_policy unset)

  Spawn an instance across multiple nodes

  Check nodeset in the instance XML


  Expected result
  ===

  Correct cellid:

  

  

  

  


  
  Actual result
  =

  
  Wrong cellid:

  

  

  

  


  Environment
  ===

  Ubuntu Xenial 16.10, OpenStack Mitaka release, Libvirt 1.3.1

  Note: This issue has been found / tested on Ubuntu KVM on Power
  (ppc64le arch), however, it *may* affect other architectures.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1602023/+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 1589358] Re: Getting error unexpected keyword 'scope' while requesting OS-FEDERATION scoped token

[OpenStack Infra]

Reviewed:  https://review.openstack.org/340577
Committed: 
https://git.openstack.org/cgit/openstack/keystone-specs/commit/?id=3e5faa81e9576d3ba7b6a427aedf9030b2a0be43
Submitter: Jenkins
Branch:master

commit 3e5faa81e9576d3ba7b6a427aedf9030b2a0be43
Author: David Stanek 
Date:   Mon Jul 11 21:18:17 2016 +

Fixes token auth documentation for OS-FEDERATION

The scope data should be inside the auth dictionary. When something is a
top level key keystone will try to pass it as a kwarg to the controller
method. The example code results in the following error message:

authenticate_for_token() got an unexpected keyword argument 'scope'

Change-Id: I3ed10bf1bd18e67e4ab616e95251695a910e6d0b
Closes-Bug: #1589358


** Changed in: keystone
   Status: In Progress => Fix Released

-- 
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/1589358

Title:
  Getting error unexpected keyword 'scope'  while requesting OS-
  FEDERATION scoped token

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  I am using stable/Liberty and configured SAML federation. I
  successfully get the unscoped token but when I request for Scoped
  token I get the error:

  {"error": {"message": "authenticate_for_token() got an unexpected
  keyword argument 'scope'", "code": 400, "title": "Bad Request"}}

  Here follows how I am making request for Scoped token:

  curl -X POST -H "Content-Type: application/json" \
-H "X-Auth-Token: 73462516f0cb4e1abf3cad52ff5f152a" \
   -d '{ "auth": { "identity": { "methods": [ "token" ], "token": { "id": 
"73462516f0cb4e1abf3cad52ff5f152a" } } }, "scope": { "project": { "id": 
"57c0b4f4e998416aa5040decf6c8a764" } } }'\
 http://localhost:5000/v3/auth/tokens

  
  The Unscoped token I received is: 73462516f0cb4e1abf3cad52ff5f152a

  I am following the following documentation:

  https://specs.openstack.org/openstack/keystone-specs/api/v3/identity-
  api-v3-os-federation-ext.html#request-a-scoped-os-federation-token

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1589358/+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 1600281] Re: ImportError: No module named api

[Armando Migliaccio]

** No longer affects: neutron

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1600281

Title:
  ImportError: No module named api

Status in tripleo:
  Fix Released

Bug description:
  The mitaka ci job is currently failing during the undercloud install
  with the following error

  
Stage[main]/Ceilometer::Keystone::Auth/Keystone::Resource::Service_identity[ceilometer]/Keystone_endpoint[regionOne/ceilometer::metering]/ensure:
 created^[[0m
  
Stage[main]/Neutron::Keystone::Auth/Keystone::Resource::Service_identity[neutron]/Keystone_endpoint[regionOne/neutron::network]/ensure:
 created^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: No handlers 
could be found for logger "oslo_config.cfg"^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: Traceback (most 
recent call last):^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns:   File 
"/usr/bin/neutron-db-manage", line 10, in ^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: 
sys.exit(main())^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns:   File 
"/usr/lib/python2.7/site-packages/neutron/db/migration/cli.py", line 749, in 
main^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: return_val 
|= bool(CONF.command.func(config, CONF.command.name))^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns:   File 
"/usr/lib/python2.7/site-packages/neutron/db/migration/cli.py", line 223, in 
do_upgrade^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: 
run_sanity_checks(config, revision)^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns:   File 
"/usr/lib/python2.7/site-packages/neutron/db/migration/cli.py", line 731, in 
run_sanity_checks^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: 
script_dir.run_env()^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns:   File 
"/usr/lib/python2.7/site-packages/alembic/script/base.py", line 397, in 
run_env^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: 
util.load_python_file(self.dir, 'env.py')^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns:   File 
"/usr/lib/python2.7/site-packages/alembic/util/pyfiles.py", line 81, in 
load_python_file^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: module = 
load_module_py(module_id, path)^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns:   File 
"/usr/lib/python2.7/site-packages/alembic/util/compat.py", line 79, in 
load_module_py^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: mod = 
imp.load_source(module_id, path, fp)^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns:   File 
"/usr/lib/python2.7/site-packages/neutron/db/migration/alembic_migrations/env.py",
 line 25, in ^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: from 
neutron.db.migration.models import head  # noqa^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns:   File 
"/usr/lib/python2.7/site-packages/neutron/db/migration/models/head.py", line 
28, in ^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: from 
neutron.db import bgp_db  # noqa^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns:   File 
"/usr/lib/python2.7/site-packages/neutron/db/bgp_db.py", line 26, in 
^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: from 
neutron_lib.api import validators^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: ImportError: No 
module named api^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]: Failed to call refresh: 
neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file 
/etc/neutron/plugin.ini upgrade head returned 1 instead of one of [0]^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]: neutron-db-manage 
--config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugin.ini 
upgrade head returned 1 instead of one of [0]^[[0m
  
Stage[main]/Swift::Keystone::Auth/Keystone::Resource::Service_identity[swift]/Keystone_user[swift]/ensure:
 created^[[0m

To manage notifications about this bug go to:
https://bugs.launchpad.net/tripleo/+bug/1600281/+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 1600281] Re: ImportError: No module named api

[Ben Nemec]

Dropping alert tag because I see the reverted package in the mitaka dlrn
repo, so this should be fixed.  In fact, I see a passed Mitaka job in
the zuul status so I'm going to mark this fixed.

** Tags removed: alert

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

Title:
  ImportError: No module named api

Status in tripleo:
  Fix Released

Bug description:
  The mitaka ci job is currently failing during the undercloud install
  with the following error

  
Stage[main]/Ceilometer::Keystone::Auth/Keystone::Resource::Service_identity[ceilometer]/Keystone_endpoint[regionOne/ceilometer::metering]/ensure:
 created^[[0m
  
Stage[main]/Neutron::Keystone::Auth/Keystone::Resource::Service_identity[neutron]/Keystone_endpoint[regionOne/neutron::network]/ensure:
 created^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: No handlers 
could be found for logger "oslo_config.cfg"^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: Traceback (most 
recent call last):^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns:   File 
"/usr/bin/neutron-db-manage", line 10, in ^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: 
sys.exit(main())^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns:   File 
"/usr/lib/python2.7/site-packages/neutron/db/migration/cli.py", line 749, in 
main^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: return_val 
|= bool(CONF.command.func(config, CONF.command.name))^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns:   File 
"/usr/lib/python2.7/site-packages/neutron/db/migration/cli.py", line 223, in 
do_upgrade^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: 
run_sanity_checks(config, revision)^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns:   File 
"/usr/lib/python2.7/site-packages/neutron/db/migration/cli.py", line 731, in 
run_sanity_checks^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: 
script_dir.run_env()^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns:   File 
"/usr/lib/python2.7/site-packages/alembic/script/base.py", line 397, in 
run_env^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: 
util.load_python_file(self.dir, 'env.py')^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns:   File 
"/usr/lib/python2.7/site-packages/alembic/util/pyfiles.py", line 81, in 
load_python_file^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: module = 
load_module_py(module_id, path)^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns:   File 
"/usr/lib/python2.7/site-packages/alembic/util/compat.py", line 79, in 
load_module_py^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: mod = 
imp.load_source(module_id, path, fp)^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns:   File 
"/usr/lib/python2.7/site-packages/neutron/db/migration/alembic_migrations/env.py",
 line 25, in ^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: from 
neutron.db.migration.models import head  # noqa^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns:   File 
"/usr/lib/python2.7/site-packages/neutron/db/migration/models/head.py", line 
28, in ^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: from 
neutron.db import bgp_db  # noqa^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns:   File 
"/usr/lib/python2.7/site-packages/neutron/db/bgp_db.py", line 26, in 
^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: from 
neutron_lib.api import validators^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: ImportError: No 
module named api^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]: Failed to call refresh: 
neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file 
/etc/neutron/plugin.ini upgrade head returned 1 instead of one of [0]^[[0m
  Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]: neutron-db-manage 
--config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugin.ini 
upgrade head returned 1 instead of one of [0]^[[0m
  
Stage[main]/Swift::Keystone::Auth/Keystone::Resource::Service_identity[swift]/Keystone_user[swift]/ensure:
 created^[[0m

To manage notifications about this bug go to:
https://bugs.launchpad.net/tripleo/+bug/1600281/+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 1600329] Re: Instance Size (flavor) column is sortable when it should not

[OpenStack Infra]

Reviewed:  https://review.openstack.org/339766
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=ea1641b2f9508339c723ba92db69668de21a58f1
Submitter: Jenkins
Branch:master

commit ea1641b2f9508339c723ba92db69668de21a58f1
Author: Eddie Ramirez 
Date:   Fri Jul 8 18:39:02 2016 +

Instance Size (flavor) column is sortable when it should not

The column size is now sortable=False. Disables the sorting function
for this column in Admin-Instances, just as the table in
Project->Instances does.

Change-Id: I25fb0e2e5afb39d226cffcea611db961196c8809
Closes-bug: #1600329


** Changed in: horizon
   Status: In Progress => Fix Released

-- 
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/1600329

Title:
  Instance Size (flavor) column is sortable when it should not

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  If you go to Project->Instances you'll notice that sorting by Size
  (flavor) column is not allowed. There's a reason why that behavior was
  disabled here https://bugs.launchpad.net/horizon/+bug/1518893 and
  patch merged here https://review.openstack.org/#/c/258407/. The patch
  only affected the table in project/instances but not admin/instances.

  How to reproduce:
  1. Go to Admin->Instances
  2. Filter by Size (allowed)
  3. Go to Project->Instances
  4. Filter by Size (not allowed)

  
  Sort by Size in Admin->Instances should be disabled.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1600329/+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 1583419] Re: Make dict.keys() PY3 compatible

[OpenStack Infra]

Reviewed:  https://review.openstack.org/337440
Committed: 
https://git.openstack.org/cgit/openstack/tacker/commit/?id=df7c0dad5ba45bc5122ebc2fe2aa3f4330d57a55
Submitter: Jenkins
Branch:master

commit df7c0dad5ba45bc5122ebc2fe2aa3f4330d57a55
Author: qinchunhua 
Date:   Tue Jul 5 02:01:20 2016 -0400

Fix dict.keys() PY3 compatible

The dict.keys()[0] will raise a TypeError in PY3,
as dict.keys() doesn't return a list any more in PY3
but a view of list.

Change-Id: I99514d57cb21bf65a59eb36b556248b9494246c7
Closes-Bug: #1583419


** Changed in: tacker
   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/1583419

Title:
  Make dict.keys() PY3 compatible

Status in Cinder:
  Fix Released
Status in neutron:
  In Progress
Status in python-cinderclient:
  Fix Released
Status in python-manilaclient:
  Fix Released
Status in python-troveclient:
  Fix Released
Status in Rally:
  Fix Released
Status in tacker:
  Fix Released
Status in tempest:
  In Progress

Bug description:
  In PY3, dict.keys() will return a view of list but not a list anymore, i.e.
  $ python3.4
  Python 3.4.3 (default, Mar 31 2016, 20:42:37) 
  >>> body={"11":"22"}
  >>> body[body.keys()[0]]
  Traceback (most recent call last):
File "", line 1, in 
  TypeError: 'dict_keys' object does not support indexing

  so for py3 compatible we should change it as follows:
  >>> body[list(body.keys())[0]]
  '22'

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1583419/+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 1602006] [NEW] openvswitch firewall driver IPv6 drop

[Basil Baby]

Public bug reported:

I was testing ovs firewall driver added in 
https://bugs.launchpad.net/neutron/+bug/1461000 .
Environment: 
OpenStack: Mitaka 
Neutron: 8.1.2
ovs 2.5
linux kernel 4.4
L3 Agent: DVR
L2: ML2 + OVS

My compute has two physical interfaces. p1p2 is used for data traffic and OVS 
using that interface 
ML2 is configured to use firewall_driver 'openvswitch'

I have created a provider network with IPv4 and IPv6 subnets. When I
tried to create an instance attaching directly to provider network, IPv4
security group rules are working as expected. But, the IPv6 traffic is
not going through even though I am seeing the traffic at the physical
interface of OVS.

Attaching my environment details and OVS flow tables for more
investigation.

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

Title:
  openvswitch firewall driver  IPv6 drop

Status in neutron:
  New

Bug description:
  I was testing ovs firewall driver added in 
https://bugs.launchpad.net/neutron/+bug/1461000 .
  Environment: 
  OpenStack: Mitaka 
  Neutron: 8.1.2
  ovs 2.5
  linux kernel 4.4
  L3 Agent: DVR
  L2: ML2 + OVS

  My compute has two physical interfaces. p1p2 is used for data traffic and OVS 
using that interface 
  ML2 is configured to use firewall_driver 'openvswitch'

  I have created a provider network with IPv4 and IPv6 subnets. When I
  tried to create an instance attaching directly to provider network,
  IPv4 security group rules are working as expected. But, the IPv6
  traffic is not going through even though I am seeing the traffic at
  the physical interface of OVS.

  Attaching my environment details and OVS flow tables for more
  investigation.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1602006/+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 1601994] [NEW] instances always packed to NUMA node 0

[Rafael Folco]

Public bug reported:

Description
===
Instances are packed into node0, always. NUMA placement criteria is undefined 
when not using CPU pinning and hw:numa_nodes=1.


Steps to reproduce
==
Create a flavor w/ hw:numa_nodes=1 (hw:cpu_policy unset)

Spawn multiple instances

Check nodeset in the instance XML


Expected result
===

Use all NUMA nodes by applying some NUMA placement criteria: Spread,
pack or random


Actual result
=
Only node 0 is used. All others are unused.


Environment
===

Ubuntu Xenial 16.10, OpenStack Mitaka release, Libvirt 1.3.1

Note: This issue has been found / tested on Ubuntu KVM on Power (ppc64le
arch), however, it affects all architectures.

** Affects: nova
 Importance: Undecided
 Assignee: Rafael Folco (rafaelfolco)
 Status: In Progress


** Tags: numa

-- 
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/1601994

Title:
  instances always packed to NUMA node 0

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  Description
  ===
  Instances are packed into node0, always. NUMA placement criteria is undefined 
when not using CPU pinning and hw:numa_nodes=1.


  Steps to reproduce
  ==
  Create a flavor w/ hw:numa_nodes=1 (hw:cpu_policy unset)

  Spawn multiple instances

  Check nodeset in the instance XML


  Expected result
  ===

  Use all NUMA nodes by applying some NUMA placement criteria: Spread,
  pack or random


  Actual result
  =
  Only node 0 is used. All others are unused.


  Environment
  ===

  Ubuntu Xenial 16.10, OpenStack Mitaka release, Libvirt 1.3.1

  Note: This issue has been found / tested on Ubuntu KVM on Power
  (ppc64le arch), however, it affects all architectures.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1601994/+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 1601986] [NEW] RuntimeError: osrandom engine already registered

[Peter Sabaini]

Public bug reported:

Horizon errors with 500 Internal Server Error.

The apache error.log logs an exception "RuntimeError: osrandom engine
already registered", cf. traceback below. We need to restart apache2 to
recover.

This happens in a non-deterministic way, ie. Horizon will function
correctly for some time after throwing this error.

Versions:

python-django-horizon2:8.0.1-0ubuntu1~cloud0 
apache2  2.4.7-1ubuntu4.10 
libapache2-mod-wsgi  3.4-4ubuntu2.1.14.04.2

Traceback:


[Mon Jul 11 20:16:46.373640 2016] [:error] [pid 2045796:tid 139828791035648] 
[remote 172.16.4.81:33908] mod_wsgi (pid=2045796): Exception occurred 
processing WSGI script 
'/usr/share/openstack-dashboard/openstack_dashboard/wsgi/django.wsgi'.
[Mon Jul 11 20:16:46.373681 2016] [:error] [pid 2045796:tid 139828791035648] 
[remote 172.16.4.81:33908] Traceback (most recent call last):
[Mon Jul 11 20:16:46.373697 2016] [:error] [pid 2045796:tid 139828791035648] 
[remote 172.16.4.81:33908]   File 
"/usr/lib/python2.7/dist-packages/django/core/handlers/wsgi.py", line 168, in 
__call__
[Mon Jul 11 20:16:46.390398 2016] [:error] [pid 2045796:tid 139828791035648] 
[remote 172.16.4.81:33908] self.load_middleware()
[Mon Jul 11 20:16:46.390420 2016] [:error] [pid 2045796:tid 139828791035648] 
[remote 172.16.4.81:33908]   File 
"/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line 46, in 
load_middleware
[Mon Jul 11 20:16:46.390515 2016] [:error] [pid 2045796:tid 139828791035648] 
[remote 172.16.4.81:33908] mw_instance = mw_class()
[Mon Jul 11 20:16:46.390525 2016] [:error] [pid 2045796:tid 139828791035648] 
[remote 172.16.4.81:33908]   File 
"/usr/lib/python2.7/dist-packages/django/middleware/locale.py", line 23, in 
__init__
[Mon Jul 11 20:16:46.394033 2016] [:error] [pid 2045796:tid 139828791035648] 
[remote 172.16.4.81:33908] for url_pattern in 
get_resolver(None).url_patterns:
[Mon Jul 11 20:16:46.394052 2016] [:error] [pid 2045796:tid 139828791035648] 
[remote 172.16.4.81:33908]   File 
"/usr/lib/python2.7/dist-packages/django/core/urlresolvers.py", line 372, in 
url_patterns
[Mon Jul 11 20:16:46.394500 2016] [:error] [pid 2045796:tid 139828791035648] 
[remote 172.16.4.81:33908] patterns = getattr(self.urlconf_module, 
"urlpatterns", self.urlconf_module)
[Mon Jul 11 20:16:46.394516 2016] [:error] [pid 2045796:tid 139828791035648] 
[remote 172.16.4.81:33908]   File 
"/usr/lib/python2.7/dist-packages/django/core/urlresolvers.py", line 366, in 
urlconf_module
[Mon Jul 11 20:16:46.394533 2016] [:error] [pid 2045796:tid 139828791035648] 
[remote 172.16.4.81:33908] self._urlconf_module = 
import_module(self.urlconf_name)
[Mon Jul 11 20:16:46.394540 2016] [:error] [pid 2045796:tid 139828791035648] 
[remote 172.16.4.81:33908]   File "/usr/lib/python2.7/importlib/__init__.py", 
line 37, in import_module
[Mon Jul 11 20:16:46.410602 2016] [:error] [pid 2045796:tid 139828791035648] 
[remote 172.16.4.81:33908] __import__(name)
[Mon Jul 11 20:16:46.410618 2016] [:error] [pid 2045796:tid 139828791035648] 
[remote 172.16.4.81:33908]   File 
"/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/urls.py",
 line 35, in 
[Mon Jul 11 20:16:46.416197 2016] [:error] [pid 2045796:tid 139828791035648] 
[remote 172.16.4.81:33908] url(r'^api/', 
include('openstack_dashboard.api.rest.urls')),
[Mon Jul 11 20:16:46.416219 2016] [:error] [pid 2045796:tid 139828791035648] 
[remote 172.16.4.81:33908]   File 
"/usr/lib/python2.7/dist-packages/django/conf/urls/__init__.py", line 28, in 
include
[Mon Jul 11 20:16:46.422868 2016] [:error] [pid 2045796:tid 139828791035648] 
[remote 172.16.4.81:33908] urlconf_module = import_module(urlconf_module)
[Mon Jul 11 20:16:46.422882 2016] [:error] [pid 2045796:tid 139828791035648] 
[remote 172.16.4.81:33908]   File "/usr/lib/python2.7/importlib/__init__.py", 
line 37, in import_module
[Mon Jul 11 20:16:46.422899 2016] [:error] [pid 2045796:tid 139828791035648] 
[remote 172.16.4.81:33908] __import__(name)
[Mon Jul 11 20:16:46.422905 2016] [:error] [pid 2045796:tid 139828791035648] 
[remote 172.16.4.81:33908]   File 
"/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/api/__init__.py",
 line 36, in 
[Mon Jul 11 20:16:46.432789 2016] [:error] [pid 2045796:tid 139828791035648] 
[remote 172.16.4.81:33908] from openstack_dashboard.api import cinder
[Mon Jul 11 20:16:46.432803 2016] [:error] [pid 2045796:tid 139828791035648] 
[remote 172.16.4.81:33908]   File 
"/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/api/cinder.py",
 line 30, in 
[Mon Jul 11 20:16:46.440814 2016] [:error] [pid 2045796:tid 139828791035648] 
[remote 172.16.4.81:33908] from cinderclient.v2.contrib import 
list_extensions as cinder_list_extensions
[Mon Jul 11 20:16:46.440829 2016] [:error] [pid 2045796:tid 139828791035648] 
[remote 172.16.4.81:33908]   File 
"/usr/lib/p

[Yahoo-eng-team] [Bug 1554859] Re: in-used volume can't be migrated for InvalidType

[OpenStack Infra]

Reviewed:  https://review.openstack.org/315864
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=ab1d40149bba06f80dde8e8645ab3ab5f16abf02
Submitter: Jenkins
Branch:master

commit ab1d40149bba06f80dde8e8645ab3ab5f16abf02
Author: weiweigu 
Date:   Fri May 13 13:05:58 2016 +0800

migration volume failed for invalid type

Boot an instance from image (create a new volume), then migrate this
volume. When migrating, source_type and destination_type will be
checked for validity at function
nova.virt.block_device.DriverVolumeBlockDevice._transform().
The valid source is volume. But source_type is
not volume, is image in the block_device_mapping table. It causes
migration failure.
Actually source_type may be image snapshot and volume. At
swap_volume, it should call the convert_volume, but not
DriverVolumeBlockDevice.

Change-Id: I36b2e2aef3345f244c05ae94225c91938450a749
Closes-Bug: #1554859


** Changed in: nova
   Status: In Progress => Fix Released

-- 
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/1554859

Title:
  in-used volume can't be migrated for InvalidType

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  Reproduction steps：
  1. Boot instance from image (create a new volume) , Instance spawned 
successfully.
  cli command:
  nova boot --flavor 1 --block-device 
id=b171c0ba-0532-4e38-be4d-05c291e88403,source=image,dest=volume,bootindex=0,size=20
 --nic net-id=e499cc2e-c6bb-4d70-9fe8-616f5399bf49  vm1

  In the cmd，b171c0ba-0532-4e38-be4d-05c291e88403 is an image.

  2. Migrate/Retype the volume which created by step 1.
  cli command:
  cinder migrate  
  Or cmd:
  cinder retype   on-demand

  3.The volume migrate/retype failed

  4.Get error infomation in nova-compute.log :

  
  2016-03-07 16:17:48.718 9817 WARNING nova.virt.libvirt.volume 
[req-8039f9e7-9d4d-48dc-9e2a-dd6073a954b0 8b34e1ab75024fcba0ea69a6fd0937c3 
181a578bc97642f2b9e153bec622f130 - - -] ISCSI volume not yet found at: vda. 
Will rescan & retry.  Try number: 0
  2016-03-07 16:17:49.503 9817 ERROR nova.compute.manager 
[req-8039f9e7-9d4d-48dc-9e2a-dd6073a954b0 8b34e1ab75024fcba0ea69a6fd0937c3 
181a578bc97642f2b9e153bec622f130 - - -] [instance: 
303abfcb-b78b-4891-848f-b1f490ac69ab] Failed to swap volume 
333df485-406c-4c51-92d1-5ba0aebfeb0d for 241abd7b-31fb-4763-86e7-3eda59744f09
  2016-03-07 16:17:49.503 9817 TRACE nova.compute.manager [instance: 
303abfcb-b78b-4891-848f-b1f490ac69ab] Traceback (most recent call last):
  2016-03-07 16:17:49.503 9817 TRACE nova.compute.manager [instance: 
303abfcb-b78b-4891-848f-b1f490ac69ab]   File 
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 5914, in 
_swap_volume
  2016-03-07 16:17:49.503 9817 TRACE nova.compute.manager [instance: 
303abfcb-b78b-4891-848f-b1f490ac69ab] resize_to)
  2016-03-07 16:17:49.503 9817 TRACE nova.compute.manager [instance: 
303abfcb-b78b-4891-848f-b1f490ac69ab]   File 
"/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 1238, in 
swap_volume
  2016-03-07 16:17:49.503 9817 TRACE nova.compute.manager [instance: 
303abfcb-b78b-4891-848f-b1f490ac69ab] driver_bdm = 
driver_block_device.DriverVolumeBlockDevice(bdm)
  2016-03-07 16:17:49.503 9817 TRACE nova.compute.manager [instance: 
303abfcb-b78b-4891-848f-b1f490ac69ab]   File 
"/usr/lib/python2.7/site-packages/nova/virt/block_device.py", line 102, in 
__init__
  2016-03-07 16:17:49.503 9817 TRACE nova.compute.manager [instance: 
303abfcb-b78b-4891-848f-b1f490ac69ab] self._transform()
  2016-03-07 16:17:49.503 9817 TRACE nova.compute.manager [instance: 
303abfcb-b78b-4891-848f-b1f490ac69ab]   File 
"/usr/lib/python2.7/site-packages/nova/virt/block_device.py", line 204, in 
_transform
  2016-03-07 16:17:49.503 9817 TRACE nova.compute.manager [instance: 
303abfcb-b78b-4891-848f-b1f490ac69ab] raise _InvalidType
  2016-03-07 16:17:49.503 9817 TRACE nova.compute.manager [instance: 
303abfcb-b78b-4891-848f-b1f490ac69ab] _InvalidType
  2016-03-07 16:17:49.503 9817 TRACE nova.compute.manager [instance: 
303abfcb-b78b-4891-848f-b1f490ac69ab]
  2016-03-07 16:17:49.771 9817 INFO nova.compute.manager 
[req-8039f9e7-9d4d-48dc-9e2a-dd6073a954b0 8b34e1ab75024fcba0ea69a6fd0937c3 
181a578bc97642f2b9e153bec622f130 - - -] [instance: 
303abfcb-b78b-4891-848f-b1f490ac69ab] swap_volume: calling Cinder 
terminate_connection for 241abd7b-31fb-4763-86e7-3eda59744f09
  2016-03-07 16:17:50.775 9817 INFO nova.compute.manager 
[req-8039f9e7-9d4d-48dc-9e2a-dd6073a954b0 8b34e1ab75024fcba0ea69a6fd0937c3 
181a578bc97642f2b9e153bec622f130 - - -] [instance: 
303abfcb-b78b-4891-848f-b1f490ac69ab] swap_volume:calling Cinder 
terminate_connection end for: 241abd7b-31fb-4763-86e7-3eda59744f09
  2016-03-07 16:17:51.239 9817 INFO nova.compute.manager 
[req-8039f9e7-9d4d-48dc-9e2a-dd6073a954b0 

[Yahoo-eng-team] [Bug 1600109] Re: Unit tests should not perform logging, but some tests still use

[David Stanek]

Marking as WONTFIX for now because I don't think this is a keystone
issue at all. If you find a place in keystone where there is a problem
feel free to reopen.

** Changed in: keystone
   Status: Incomplete => Won't Fix

** Changed in: python-keystoneclient
   Status: Incomplete => Won't Fix

-- 
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/1600109

Title:
  Unit tests should not perform logging,but some tests still use

Status in Ceilometer:
  Incomplete
Status in Cinder:
  Incomplete
Status in Glance:
  Incomplete
Status in glance_store:
  Incomplete
Status in OpenStack Identity (keystone):
  Won't Fix
Status in Magnum:
  Incomplete
Status in neutron:
  Incomplete
Status in OpenStack Compute (nova):
  Incomplete
Status in os-brick:
  Incomplete
Status in python-cinderclient:
  Incomplete
Status in python-glanceclient:
  Incomplete
Status in python-heatclient:
  Incomplete
Status in python-keystoneclient:
  Won't Fix
Status in python-neutronclient:
  Incomplete
Status in python-novaclient:
  Incomplete
Status in python-rackclient:
  Incomplete
Status in python-swiftclient:
  Incomplete
Status in rack:
  Incomplete
Status in Rally:
  Incomplete
Status in OpenStack Object Storage (swift):
  Incomplete
Status in tempest:
  Incomplete
Status in OpenStack DBaaS (Trove):
  Incomplete

Bug description:
  We shuld remove the logging

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1600109/+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 1601964] [NEW] Policy file distribution breaks security group panel

[Logan V]

Public bug reported:

When using POLICY_FILES_PATH and POLICY_FILES with Mitaka Horizon +
Default nova/neutron policy files, the security group CRUD options are
not showing up.

After I add "create_security_group": "" to the neutron policy file, the
create button shows up. This behavior did not occur on Liberty, I just
began seeing it as I started prepping for a Mitaka upgrade.

Horizon @ 9075f06d014e538e8e17af320ef323129aaa3b40
Nova @ 98b38df57bfed3802ce60ee52e4450871fccdbfa
Neutron @ cda226b9da1d4e4b1c045609e3a8352674b772df

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

Title:
  Policy file distribution breaks security group panel

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  When using POLICY_FILES_PATH and POLICY_FILES with Mitaka Horizon +
  Default nova/neutron policy files, the security group CRUD options are
  not showing up.

  After I add "create_security_group": "" to the neutron policy file,
  the create button shows up. This behavior did not occur on Liberty, I
  just began seeing it as I started prepping for a Mitaka upgrade.

  Horizon @ 9075f06d014e538e8e17af320ef323129aaa3b40
  Nova @ 98b38df57bfed3802ce60ee52e4450871fccdbfa
  Neutron @ cda226b9da1d4e4b1c045609e3a8352674b772df

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1601964/+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 1546462] Re: can not reload dnsmasq after update dhcp port

[Ryan Selden]

I am unable to reproduce this bug. What version of neutron are you
using? Here are my steps, done on master:

neutron net-create test2
neutron subnet-create --name test2 test2 30.0.0.0/24  #(dhcp is enabled, I 
checked)
neutron port-list | grep "30.0."  #shows one port, as expected
neutron port-delete   #ID from above port-list
neutron dhcp-agent-list-hosting-net test2
neutron dhcp-agent-network-remove  test2 #ID from above
neutron dhcp-agent-network-add  test2#Same ID
neutron port-list | grep "30.0.0"  #Note that the port IP address is NOT 
different
neutron port-update --fixed-ip subnet_id=,ip_address=30.0.0.4 
 #Success

There were no errors.

** Changed in: neutron
   Status: Incomplete => 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/1546462

Title:
  can not reload dnsmasq after update dhcp port

Status in neutron:
  Invalid

Bug description:
  after create_dhcp_port [1], the port would not be putted into cache ,
  so if we update the dhcp port [2], there would be a NoneType error.
  as showed below:

  2016-02-17 18:10:53.121 60074 ERROR oslo_messaging.rpc.dispatcher 
[req-0e99287a-7a91-46e2-9c36-d8ecb096de58 ] Exception during message handling: 
'NoneType' object has no attribute '__getitem__'
  2016-02-17 18:10:53.121 60074 TRACE oslo_messaging.rpc.dispatcher Traceback 
(most recent call last):
  2016-02-17 18:10:53.121 60074 TRACE oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 142, 
in _dispatch_and_reply
  2016-02-17 18:10:53.121 60074 TRACE oslo_messaging.rpc.dispatcher 
executor_callback))
  2016-02-17 18:10:53.121 60074 TRACE oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 186, 
in _dispatch
  2016-02-17 18:10:53.121 60074 TRACE oslo_messaging.rpc.dispatcher 
executor_callback)
  2016-02-17 18:10:53.121 60074 TRACE oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 130, 
in _do_dispatch
  2016-02-17 18:10:53.121 60074 TRACE oslo_messaging.rpc.dispatcher result 
= func(ctxt, **new_args)
  2016-02-17 18:10:53.121 60074 TRACE oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py", line 445, in 
inner
  2016-02-17 18:10:53.121 60074 TRACE oslo_messaging.rpc.dispatcher return 
f(*args, **kwargs)
  2016-02-17 18:10:53.121 60074 TRACE oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/neutron/agent/dhcp/agent.py", line 331, in 
port_update_end
  2016-02-17 18:10:53.121 60074 TRACE oslo_messaging.rpc.dispatcher old_ips 
= {i['ip_address'] for i in orig['fixed_ips'] or []}
  2016-02-17 18:10:53.121 60074 TRACE oslo_messaging.rpc.dispatcher TypeError: 
'NoneType' object has no attribute '__getitem__'
  2016-02-17 18:10:53.121 60074 TRACE oslo_messaging.rpc.dispatcher

  [1] 
https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L449
  [2] 
https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L332

  in neutron.conf:
  dhcp_agents_per_network = 1

  the bug can be reproduce as below steps:
  1. create network1
  2. create subnet1(10.0.0.0/24), enable dhcp, then would create a dhcp port 
such as 10.0.0.2,
  3. delete the dhcp port 10.0.0.2
  4. delete the dhcp agent such as DhcpAgent1
  5. re-added network1 to the dhcp agent1, then would be a new port 10.0.0.3
  6. update the new port from 10.0.0.3 to 10.0.0.2
  then there would be an error..

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1546462/+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 1600691] Re: Should not create overlapped subnetpool in one tenant

[John Perkins]

** Changed in: neutron
   Importance: Undecided => Wishlist

** Changed in: neutron
   Status: New => Opinion

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1600691

Title:
  Should not create overlapped subnetpool in one tenant

Status in neutron:
  Opinion

Bug description:
  After adding address scope in Mitaka, the openstack can create
  subnetpool with specified address scope, and in the same address
  scope, we can not create the overlapping subnetpool.

  As we also known, the BGP depends on these two features to get the
  advertised tenant networks. So in order to get better subnet
  management, we'd better create subnet from the subnetpool and add the
  address scope.

  In order to backward compatibilities, the subnetpool can be created
  without address scope, see below, the address_scope_id is empty.

  yangyubj@yang-devstack-ubuntu-1604:/opt/stack/logs$ neutron subnetpool-show 
07f8a928-afb3-4ba8-ba46-cb70c6d9c073
  +---+--+
  | Field | Value|
  +---+--+
  | address_scope_id  |  |
  | created_at| 2016-06-01T09:32:52  |
  | default_prefixlen | 24   |
  | default_quota |  |
  | description   |  |
  | id| 07f8a928-afb3-4ba8-ba46-cb70c6d9c073 |
  | ip_version| 4|
  | is_default| True |
  | max_prefixlen | 32   |
  | min_prefixlen | 8|
  | name  | shared-default-subnetpool|
  | prefixes  | 10.0.0.0/8   |
  | shared| True |
  | tenant_id | 21734c4383284cf9906b7fe8246bffb1 |
  | updated_at| 2016-06-01T09:32:52  |
  +---+--+

  And the user can be continuous to create overlapping subnetpool with
  the empty address scope id. If the address scope id is specified, the
  customer can not create the overlapping subnetpool.

  So IMO, for the best practice, we can not allow the user to create
  overlapping subnetpool when the address scope id is empty.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1600691/+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 1601929] [NEW] Relax the requirement for mappings to result in group memberships

[Steve Martinelli]

Public bug reported:

we should allow for mappings to result in per-user assignments, so relax
the requirement that a "group" be always used.

** Affects: keystone
 Importance: Medium
 Assignee: Ron De Rose (ronald-de-rose)
 Status: Triaged


** Tags: federation

-- 
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/1601929

Title:
  Relax the requirement for mappings to result in group memberships

Status in OpenStack Identity (keystone):
  Triaged

Bug description:
  we should allow for mappings to result in per-user assignments, so
  relax the requirement that a "group" be always used.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1601929/+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 1601924] [NEW] [api-ref] Document OS-TRUST

[Steve Martinelli]

Public bug reported:

The current APIs for OS-TRUST are not complete:

 - 
http://developer.openstack.org/api-ref/identity/v3-ext/index.html#os-trust-api
 - 
http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-trust-ext.html

** Affects: keystone
 Importance: Low
 Status: Confirmed


** Tags: api-ref

-- 
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/1601924

Title:
  [api-ref] Document OS-TRUST

Status in OpenStack Identity (keystone):
  Confirmed

Bug description:
  The current APIs for OS-TRUST are not complete:

   - 
http://developer.openstack.org/api-ref/identity/v3-ext/index.html#os-trust-api
   - 
http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-trust-ext.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1601924/+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 1585986] Re: Add CLI command about region

[Steve Martinelli]

** Changed in: keystone
   Status: Incomplete => 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/1585986

Title:
  Add CLI command about region

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  Now we have no commands that are related to region the current
  version. I think we needs to create a set of commands for
  administrator. - "region-create/delete/list/get/update".

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1585986/+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 1566607] Re: [api-ref][Show user details] miss request parameter

[Steve Martinelli]

indeed, only the ID is necessary to show a user.

** Changed in: keystone
   Status: Confirmed => Invalid

** Tags removed: keystone

-- 
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/1566607

Title:
  [api-ref][Show user details] miss request parameter

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  Show user details [1] miss parameters: name, enabled, email, id, user
  and username

  [1]http://developer.openstack.org/api-ref-identity-admin-v2.html
  #admin-showUser

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1566607/+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 1517705] Re: Move federation extension into keystone core

[Steve Martinelli]

** Changed in: openstack-manuals
   Status: Confirmed => Invalid

** Changed in: keystone
   Status: Confirmed => Fix Released

** Changed in: keystone
   Importance: Undecided => Medium

-- 
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/1517705

Title:
  Move federation extension into keystone core

Status in OpenStack Identity (keystone):
  Fix Released
Status in openstack-manuals:
  Invalid

Bug description:
  https://review.openstack.org/214775
  commit cbefe7c7b83b5f940f817adf60a4be35bd324775
  Author: Steve Martinelli 
  Date:   Sun Oct 11 03:01:05 2015 -0400

  Move federation extension into keystone core
  
  Remove federation as an extension and move it to a core resource.
  For now we leave the database migrations in the extension directory
  until we have a general policy for merging these into core.
  
  Some instances of federation constants were removed because
  they were causing a circular dependency, these can be refactored in
  a later patch.
  
  DocImpact: You should no longer run the migrations for this extension
  Implements: bp move-extensions
  
  Co-Authored-By: Nithya Renganathan 
  
  Change-Id: If5857a6ee4c7c527929069b25beab40f4c5d87e2

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1517705/+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 1601910] [NEW] drop support for EPHEMERAL user type in mapping

[Steve Martinelli]

Public bug reported:

With the shadow users implementation, federated users are no longer
emphemeral. Support for specifying this option in a mapping should be
removed. The option should be ignored and should result in a log that
indicates a timeframe for removal (2 cycles)

See this blueprint for details:
https://blueprints.launchpad.net/keystone/+spec/shadow-users-newton

See this review for a patch: https://review.openstack.org/#/c/296639/

** Affects: keystone
 Importance: Medium
 Assignee: Ron De Rose (ronald-de-rose)
 Status: In Progress


** Tags: federation

-- 
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/1601910

Title:
  drop support for EPHEMERAL user type in mapping

Status in OpenStack Identity (keystone):
  In Progress

Bug description:
  With the shadow users implementation, federated users are no longer
  emphemeral. Support for specifying this option in a mapping should be
  removed. The option should be ignored and should result in a log that
  indicates a timeframe for removal (2 cycles)

  See this blueprint for details:
  https://blueprints.launchpad.net/keystone/+spec/shadow-users-newton

  See this review for a patch: https://review.openstack.org/#/c/296639/

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1601910/+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 1575938] Re: Instance path in / if instance-id starts with '/'

[Scott Moser]

fix is now released to xenial under bug 1595302.  daily cloud-images
with this newer version of cloud-init should appear in the next few
days.  Any image with a serial number *newer* than 20160707 should have
cloud-init at 0.7.7~bzr1246-0ubuntu1~16.04.1 .

** Changed in: cloud-init (Ubuntu Xenial)
   Status: In Progress => Fix Released

-- 
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/1575938

Title:
  Instance path in / if instance-id starts with '/'

Status in cloud-init:
  In Progress
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released

Bug description:
  A cloud using the Ec2 datasource has an instance-id metadata value in
  the form:

  /Compute-$TENANT/$CLOUDUSERNAME/$UUID

  The leading '/' causes /var/lib/cloud/instance to link to
  /Compute-$TENANT/$CLOUDUSERNAME/$UUID rather than
  /var/lib/cloud/instances/Compute-$TENANT/$CLOUDUSERNAME/$UUID

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1575938/+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 1575055] Re: check_instance_id() error on reboots when using config-drive

[Frank Heimes]

** Changed in: ubuntu-z-systems
   Status: Fix Committed => Fix Released

-- 
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/1575055

Title:
  check_instance_id() error on reboots when using config-drive

Status in cloud-init:
  Fix Committed
Status in Ubuntu on IBM z Systems:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released

Bug description:
  Problem Description
  =
  When using a config-drive to provide meta-data to cloud-init on ubuntu (for 
Linux guest running in KVM for z Systems) we get a check_instance_id() error 
whenever we soft reboot after the (successful) initial boot.

  The error shows:

  [5.283203] cloud-init[1637]: Cloud-init v. 0.7.7 running 'init-local' at 
Sat, 23 Apr 2016 00:50:58 +. Up 5.25 seconds.
  [5.283368] cloud-init[1637]: 2016-04-22 20:50:58,839 - util.py[WARNING]: 
failed of stage init-local
  [5.286659] cloud-init[1637]: failed run of stage init-local
  [5.286770] cloud-init[1637]: 

  [5.286849] cloud-init[1637]: Traceback (most recent call last):
  [5.286924] cloud-init[1637]:   File "/usr/bin/cloud-init", line 520, in 
status_wrapper
  [5.286998] cloud-init[1637]: ret = functor(name, args)
  [5.287079] cloud-init[1637]:   File "/usr/bin/cloud-init", line 250, in 
main_init
  [5.287152] cloud-init[1637]: init.fetch(existing=existing)
  [5.287225] cloud-init[1637]:   File 
"/usr/lib/python3/dist-packages/cloudinit/stages.py", line 322, in fetch
  [5.287298] cloud-init[1637]: return 
self._get_data_source(existing=existing)
  [5.287371] cloud-init[1637]:   File 
"/usr/lib/python3/dist-packages/cloudinit/stages.py", line 229, in 
_get_data_source
  [5.287445] cloud-init[1637]: ds.check_instance_id(self.cfg)):
  [5.287518] cloud-init[1637]: TypeError: check_instance_id() takes 1 
positional argument but 2 were given
  [5.287592] cloud-init[1637]: 

  [FAILED] Failed to start Initial cloud-init job (pre-networking).

  
  The failure of the init-local pre-networking does seem to lead to a boot up 
delay as cloud-init tries to search for networking outside of the already saved 
networking data.   

  Otherwise the error is purely cosmetic as later init modules find (or
  let existing IP configuration take over) and bring up the correct
  interfaces.

  The original problem was found outside of openstack with stand-alone
  cloud-config iso images.  But have been able to reproduce the problem
  within an openstack ICM environment.

  Team has had some success getting around the problem by patching the
  check_instance_id function in /usr/lib/python3/dist-
  packages/cloudinit/sources/DataSourceConfigDrive.py so that it
  accepted an extra argument, ex:

  ubuntu@markvercd:~$ sudo cat check_instance_id.patch 
  --- /usr/lib/python3/dist-packages/cloudinit/sources/DataSourceConfigDrive.py 
2016-04-06 15:29:59.0 +
  +++ 
/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceConfigDrive.py.new   
  2016-04-11 22:53:47.799867139 +
  @@ -155,7 +155,7 @@
   
   return True
   
  -def check_instance_id(self):
  +def check_instance_id(self,somecfg):
   # quickly (local check only) if self.instance_id is still valid
   return 
sources.instance_id_matches_system_uuid(self.get_instance_id())
   
  ubuntu@markvercd:~$ 

  ---uname output---
  Linux k6mpathcl.pokprv.stglabs.ibm.com 4.4.0-21-generic #37-Ubuntu SMP Mon 
Apr 18 18:31:26 UTC 2016 s390x s390x s390x GNU/Linux
   
  Machine Type = KVM guest on a z13 (2827-732) LPAR 

  Steps to Reproduce
  =
   1) set up ubuntu guest image with cloud-init
  2) pass in iso image with cloud-config data in cdrom device
  3) boot up successfully with cloud-config data
  4) attempt a soft reboot.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1575055/+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 1572730] Re: The _sync_power_states task should filter out instances.task_state != None up front

[Sarafraj Singh]

This is no longer valid if you exclude all the things that are not running a 
task.
I think the cloud steady state will be no instances running a task, so I don't 
think we need to worry about the extra DB load of getting instances that are 
running a task. It should be tiny.

** Changed in: nova
   Status: In Progress => Won't Fix

-- 
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/1572730

Title:
  The _sync_power_states task should filter out instances.task_state !=
  None up front

Status in OpenStack Compute (nova):
  Won't Fix

Bug description:
  The _sync_power_states periodic task queries all instances on the
  compute host:

  
https://github.com/openstack/nova/blob/4ad414f3b1216393301ef268a64e61ca1a3d5be9/nova/compute/manager.py#L6164

  Then later it skips any that are in the middle of an operation:

  
https://github.com/openstack/nova/blob/4ad414f3b1216393301ef268a64e61ca1a3d5be9/nova/compute/manager.py#L6269

  We should avoid the roundtrip to the DB and RPC traffic to load up all
  of the instances on the compute host that are in the middle of a task
  and will just be skipped in code anyway and filter out the instance
  list by task_state in the initial DB query.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1572730/+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 1596690] Re: restoring from datasource without dsmode causes stacktrace

[Launchpad Bug Tracker]

This bug was fixed in the package cloud-init -
0.7.7~bzr1246-0ubuntu1~16.04.1

---
cloud-init (0.7.7~bzr1246-0ubuntu1~16.04.1) xenial-proposed; urgency=medium

  * New upstream snapshot.
- fix restoring from a datasource that did not have dsmode (LP: #1596690)

cloud-init (0.7.7~bzr1245-0ubuntu1~16.04.1) xenial-proposed;
urgency=medium

  * debian/new-upstream-snapshot: minor change supporting revision
passed in as an argument.
  * debian/control: Build-Depends on python3-unittest2
  * SRU Upstream to 16.04 (LP: #1595302).
- user_data: fix error when user-data is not utf-8 decodable
- write_files: if no permissions are provided, use the default without
  logging a warning.
- do not write /etc/systemd/network/50-cloud-init-*.link files
- fix several potential errors identified by pylint.
- move 'main' into cloudinit/cmd/ for easier testing
- Remove trailing dot from GCE metadata URL [Phil Roche]
- Refactor cloudinit networking module to improve testing
- Change missing Cheetah log warning to debug [Andrew Jorgensen]
- network configuration improvements
  - centrally handle 'dsmode' (DataSource mode) to be 'local' or 'net.
  - support networking information being read on dreamcompute
  - support reading and applying networking information on SmartOS
  - improve reading networking from openstack network_data.json
  - support for renaming devices in a container.
  - remove blocking of udev rules
- Apt sources configuration improvements
- cloud-config specified on kernel command line will now override
  system settings.
- fix timestamp in reporting events.
- Paths: fix instance path if datasource's id has a '/'.
- Config Drive: fix check_instance_id signature.
- cloudstack: Only use DHCPv4 lease files as a datasource

 -- Scott Moser   Mon, 27 Jun 2016 16:31:37 -0400

** Changed in: cloud-init (Ubuntu Xenial)
   Status: Fix Committed => Fix Released

-- 
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/1596690

Title:
  restoring from datasource without dsmode causes stacktrace

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released

Bug description:
  On reboot, if cloud-init found a cached /var/lib/cloud/instance/obj.pkl it 
would restore from it.
  If that class did not have a 'dsmode', then main would stack trace like:
  | "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 530, in 
status_wrapper
  | ret = functor(name, args)
  |   File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 247, in 
main_init
  | if mode == sources.DSMODE_NETWORK and init.datasource.dsmode != mode:
  | AttributeError: 'DataSourceAzureNet' object has no attribute 'dsmode'

  This would affect upgrade and reboot on any datasource that did not
  have a dsmode previously.

  That list is
cloudinit/sources/DataSourceAzure.py
cloudinit/sources/DataSourceBigstep.py
cloudinit/sources/DataSourceCloudStack.py
cloudinit/sources/DataSourceDigitalOcean.py
cloudinit/sources/DataSourceEc2.py
cloudinit/sources/DataSourceGCE.py
cloudinit/sources/DataSourceMAAS.py
cloudinit/sources/DataSourceNone.py
cloudinit/sources/DataSourceOVF.py
cloudinit/sources/DataSourceSmartOS.py

  The non-broken datasources then were the ones that previously had a dsmode:
cloudinit/sources/DataSourceAltCloud.py
cloudinit/sources/DataSourceCloudSigma.py
cloudinit/sources/DataSourceConfigDrive.py
cloudinit/sources/DataSourceNoCloud.py
cloudinit/sources/DataSourceOpenNebula.py
cloudinit/sources/DataSourceOpenStack.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1596690/+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 1575055] Re: check_instance_id() error on reboots when using config-drive

[Scott Moser]

fix is now released to xenial under bug 1595302.  daily cloud-images
with this newer version of cloud-init should appear in the next few
days.  Any image with a serial number *newer* than 20160707 should have
cloud-init at 0.7.7~bzr1246-0ubuntu1~16.04.1 .

** Changed in: cloud-init (Ubuntu Xenial)
   Status: Fix Committed => Fix Released

-- 
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/1575055

Title:
  check_instance_id() error on reboots when using config-drive

Status in cloud-init:
  Fix Committed
Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released

Bug description:
  Problem Description
  =
  When using a config-drive to provide meta-data to cloud-init on ubuntu (for 
Linux guest running in KVM for z Systems) we get a check_instance_id() error 
whenever we soft reboot after the (successful) initial boot.

  The error shows:

  [5.283203] cloud-init[1637]: Cloud-init v. 0.7.7 running 'init-local' at 
Sat, 23 Apr 2016 00:50:58 +. Up 5.25 seconds.
  [5.283368] cloud-init[1637]: 2016-04-22 20:50:58,839 - util.py[WARNING]: 
failed of stage init-local
  [5.286659] cloud-init[1637]: failed run of stage init-local
  [5.286770] cloud-init[1637]: 

  [5.286849] cloud-init[1637]: Traceback (most recent call last):
  [5.286924] cloud-init[1637]:   File "/usr/bin/cloud-init", line 520, in 
status_wrapper
  [5.286998] cloud-init[1637]: ret = functor(name, args)
  [5.287079] cloud-init[1637]:   File "/usr/bin/cloud-init", line 250, in 
main_init
  [5.287152] cloud-init[1637]: init.fetch(existing=existing)
  [5.287225] cloud-init[1637]:   File 
"/usr/lib/python3/dist-packages/cloudinit/stages.py", line 322, in fetch
  [5.287298] cloud-init[1637]: return 
self._get_data_source(existing=existing)
  [5.287371] cloud-init[1637]:   File 
"/usr/lib/python3/dist-packages/cloudinit/stages.py", line 229, in 
_get_data_source
  [5.287445] cloud-init[1637]: ds.check_instance_id(self.cfg)):
  [5.287518] cloud-init[1637]: TypeError: check_instance_id() takes 1 
positional argument but 2 were given
  [5.287592] cloud-init[1637]: 

  [FAILED] Failed to start Initial cloud-init job (pre-networking).

  
  The failure of the init-local pre-networking does seem to lead to a boot up 
delay as cloud-init tries to search for networking outside of the already saved 
networking data.   

  Otherwise the error is purely cosmetic as later init modules find (or
  let existing IP configuration take over) and bring up the correct
  interfaces.

  The original problem was found outside of openstack with stand-alone
  cloud-config iso images.  But have been able to reproduce the problem
  within an openstack ICM environment.

  Team has had some success getting around the problem by patching the
  check_instance_id function in /usr/lib/python3/dist-
  packages/cloudinit/sources/DataSourceConfigDrive.py so that it
  accepted an extra argument, ex:

  ubuntu@markvercd:~$ sudo cat check_instance_id.patch 
  --- /usr/lib/python3/dist-packages/cloudinit/sources/DataSourceConfigDrive.py 
2016-04-06 15:29:59.0 +
  +++ 
/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceConfigDrive.py.new   
  2016-04-11 22:53:47.799867139 +
  @@ -155,7 +155,7 @@
   
   return True
   
  -def check_instance_id(self):
  +def check_instance_id(self,somecfg):
   # quickly (local check only) if self.instance_id is still valid
   return 
sources.instance_id_matches_system_uuid(self.get_instance_id())
   
  ubuntu@markvercd:~$ 

  ---uname output---
  Linux k6mpathcl.pokprv.stglabs.ibm.com 4.4.0-21-generic #37-Ubuntu SMP Mon 
Apr 18 18:31:26 UTC 2016 s390x s390x s390x GNU/Linux
   
  Machine Type = KVM guest on a z13 (2827-732) LPAR 

  Steps to Reproduce
  =
   1) set up ubuntu guest image with cloud-init
  2) pass in iso image with cloud-config data in cdrom device
  3) boot up successfully with cloud-config data
  4) attempt a soft reboot.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1575055/+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 1553158] Re: [SRU] Add cloud-init data source for BigStep

[Launchpad Bug Tracker]

This bug was fixed in the package cloud-init - 0.7.5-0ubuntu1.19

---
cloud-init (0.7.5-0ubuntu1.19) trusty; urgency=medium

  * Bigstep:
- debian/patches/lp-1553158-bigstep.patch (LP: #1553158):
- Add the data source for the Bigstep cloud
- Enable password changing via a hashed string

 -- Daniel Watkins   Tue, 31 May 2016
13:42:32 +0100

** Changed in: cloud-init (Ubuntu Trusty)
   Status: Fix Committed => Fix Released

-- 
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/1553158

Title:
  [SRU] Add cloud-init data source for BigStep

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Trusty:
  Fix Released

Bug description:
  [Impact]

  Users on older versions of Ubuntu cannot use the BigStep cloud.

  [Test Case]

  1) Launch an Ubuntu image with the fixed version of cloud-init in the BigStep 
cloud
  2) Successfully SSH in to it

  [Regression Potential]

  Low; this adds a new file which is only read on instances that are
  explicitly configured to read from the BigStep data source.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1553158/+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 1532072] Re: cloud-init fails with UnicodeDecodeError

[Scott Moser]

fix is now released to xenial under bug 1595302.  daily cloud-images
with this newer version of cloud-init should appear in the next few
days.  Any image with a serial number *newer* than 20160707 should have
cloud-init at 0.7.7~bzr1246-0ubuntu1~16.04.1 .

** Changed in: cloud-init (Ubuntu Xenial)
   Status: Fix Committed => Fix Released

-- 
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/1532072

Title:
  cloud-init fails with UnicodeDecodeError

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released
Status in cloud-init source package in Yakkety:
  Fix Released

Bug description:
  I'm running the latest Ubuntu Wily AMI on EC2 (ami-15b7e87f). When the
  instance boots up cloud-init fails with the following exception:

  [   69.519513] cloud-init[901]: 2016-01-08 03:43:00,902 - util.py[WARNING]: 
failed of stage init
  [   69.551842] cloud-init[901]: failed run of stage init
  [   69.552029] cloud-init[901]: 

  [   69.552427] cloud-init[901]: Traceback (most recent call last):
  [   69.552591] cloud-init[901]: File "/usr/bin/cloud-init", line 509, in 
status_wrapper
  [   69.557342] cloud-init[901]: ret = functor(name, args)
  [   69.557524] cloud-init[901]: File "/usr/bin/cloud-init", line 272, in 
main_init
  [   69.557695] cloud-init[901]: init.update()
  [   69.557859] cloud-init[901]: File 
"/usr/lib/python3/dist-packages/cloudinit/stages.py", line 351, in update
  [   69.558020] cloud-init[901]: self._store_userdata()
  [   69.558185] cloud-init[901]: File 
"/usr/lib/python3/dist-packages/cloudinit/stages.py", line 360, in 
_store_userdata
  [   69.558344] cloud-init[901]: processed_ud = self.datasource.get_userdata()
  [   69.558502] cloud-init[901]: File 
"/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line 83, in 
get_userdata
  [   69.558660] cloud-init[901]: self.userdata = 
self.ud_proc.process(self.get_userdata_raw())
  [   69.558832] cloud-init[901]: File 
"/usr/lib/python3/dist-packages/cloudinit/user_data.py", line 96, in process
  [   69.560273] cloud-init[901]: self._process_msg(convert_string(blob), 
accumulating_msg)
  [   69.560440] cloud-init[901]: File 
"/usr/lib/python3/dist-packages/cloudinit/user_data.py", line 342, in 
convert_string
  [   69.560603] cloud-init[901]: data = 
util.decode_binary(util.decomp_gzip(raw_data))
  [   69.560764] cloud-init[901]: File 
"/usr/lib/python3/dist-packages/cloudinit/util.py", line 86, in decode_binary
  [   69.560926] cloud-init[901]: return blob.decode(encoding)
  [   69.561094] cloud-init[901]: UnicodeDecodeError: 'utf-8' codec can't 
decode byte 0x8d in position 0: invalid start byte

  I've tracked it down to the following commit:

  https://github.com/number5/cloud-
  init/commit/a7835683afd19f1ae291cc93f008320a7820b24f#diff-
  a543026d533dadf4f39b57d1f65dc1b7R339

  The user-data that is set on our instances is beyond my control.
  Here's a sample of it:

  
b'\x8dV\xd9\x8e\xa3H\x16\xfd\x95\x92_\x9d\x99\xec\x06\xf2\x8d\xc5,\x06\x8c1;\xa3\xd1\x88}3;\x18C\xab\xff\xbd\xa32kT\xea\x87\x1e\r\x0f!\xc5\xb9q\xe3\x9es\xe3@\xf0\xc7!\n\xa7\xd4\xbe\xab\x87\xcfC1\xcf\xfd\'\x04=\xba8|\x14\xdd4\x7f\x9eh\x1a\x86\xa2\xa5|$\x13\x14\xe6i;\x9b\xe9\xf8LG\xe8\xf0v\x98\xe6p\x9c\x97\xde*\x9b\xb4[\x00\x1ewm2\x1d>O0\xfcv\xa8\xd3M\x0b[\x9002\x8f\xbc\x1b\xcb\xb9h\xaea\x93\x82\n\xe6\xd2z\x04L\x83\xfcy\\\xa6\xf9\x1fV\xdd\x14\xd9\x03K\x9at\x0e\xf9p\x0e\x0f\x9f\x7f\x00\x92M\xd4u\x1f\xa0\xf8Tv\xed\xc7\xd4\xa7q\x99\x95\xf1G\x02\xe2\x1f?\t\xcf\x00\x06\xa9\x13\x06\x04|/~\xffb\xfc>\xa6\x8f\x14(|_\xa6\xf7\x14\x81\x88\x0f\x04~\xd7\xf9w0\xc20\x05aT\x96d\x08\x1a\xa1\x08\x89#d\x16#h\x1ag\x08\x15\xa5p\x8a\x00)\xa7\x13uJ\xe2\x08\x8e\x00\x9b_\x0c\xa6\xaf\x0e|de\x0b\x88\xf7c\xd9\xce\xa0\xea\x89BI\x14\xa7\t\xb0%\r#\x08E\xa2
  
!\\\xa7\x8f\xaf.\xa5\x890v\r\xfb\x95\x0f\x16\x03\xe5\xe9\xef\x06\x9a\xf1X\xf6\xf3\x7f`\x10\xf8\x95\xf3E\x9b\x99\xa6\xb4\x89\x1e\x9b\xfa[\xda\xff\xaf\x8a\x8e\x93,\xca\xd2\x88"\xf18\xa2\x93\x98\xa4q\x84HQ\x92"C\x9c\x86\xd18\xc6\x12\x84\xa4\x888\xcc2\x1c\x8dOx\x94\xd11\ng\t\t\xc0\x0cO\xc2\xdfj\xcb\x16\xd0l\xe3\xf4\x1f\x1a>\xfdf\xfd\x9d\xf0\xed\x0f\xe7\xfb\x94@\xf0\xef\xc4\x0e\x7f\xbe\x1d\x96)\xb5\x96\xb6M\x1fB7J\xc0o\x87\xcf\x9f\xfd\xf8;~i\xa6\xff\xc2e\xdevc\xca\xa5\xe3\xfc\xb3z8\xa7\\\x91\xc65\x08g\xe1c\x02\xf1\xf4\x11Ns\x19\xcb\rh\x0b\xd7\xb5Y\x99/\xe3\x17599|\xa2\'\x14\xc1q\n\x98\xedk\xe7[7\xce_
  
\x8a\xbf}y\xfd6v\xaf\xed\x1b\xc5O\x04\x8d\xbd\x1d\xaaf\xfa5\'P\xf2\xcb\xc8\xe6\x0c\xea\x1f>\xffu\xa8@\xd5\xb7\x03\xb4`G\xd2`\xc0#\xff\x1c\xd8\x9f\x03c0R\xe0\xbe\x8a\x18\xbb\xf7\xfe\n\xe6\x8e\x9c\xc9\x18\xc9\xff\x8cW\x15\xc71~\xb7\xf2\xb9\xaf(\xab\xcf\xb2\xccy`\x8a3\xcb\x186\xc3\xca2\x9b<\x8c\xa3\x0f{\xbcBs\xa1\xe3\xd7\x1b\x8f3F\xe7c\xbd\xc9\xcbF\xe3(\xbc\xff\xcaP}h\xdc\xba\xa4\xb6a\xec

[Yahoo-eng-team] [Bug 1576273] Re: CloudStack datasource fails to find DHCP lease if IPv6 present

[Scott Moser]

fix is now released to xenial under bug 1595302.  daily cloud-images
with this newer version of cloud-init should appear in the next few
days.  Any image with a serial number *newer* than 20160707 should have
cloud-init at 0.7.7~bzr1246-0ubuntu1~16.04.1 .

** Changed in: cloud-init (Ubuntu Xenial)
   Status: Fix Committed => Fix Released

-- 
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/1576273

Title:
  CloudStack datasource fails to find DHCP lease if IPv6 present

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released

Bug description:
  The CloudStack data source looks in /var/lib/dhcp for DHCP lease files
  and compares the timestamps.

  If you have a dhclient.leases and dhclient6.leases file present it
  will look in the dhclient6.leases file for a DHCP server to connect
  to.

  The fix for this is rather simple, change a if-statement so that it
  checks if the leases file starts with 'dhclient.'

  if file_name.startswith("dhclient.") and \
 (file_name.endswith(".lease") or file_name.endswith(".leases")):

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1576273/+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 1582323] Re: Commissioning fails when competing cloud metadata resides on disk

[Scott Moser]

fix is now released to xenial under bug 1595302.  daily cloud-images
with this newer version of cloud-init should appear in the next few
days.  Any image with a serial number *newer* than 20160707 should have
cloud-init at 0.7.7~bzr1246-0ubuntu1~16.04.1 .

** Changed in: cloud-init (Ubuntu Xenial)
   Status: In Progress => Fix Released

-- 
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/1582323

Title:
  Commissioning fails when competing cloud metadata resides on disk

Status in cloud-init:
  Fix Committed
Status in MAAS:
  Triaged
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released

Bug description:
  A customer reused hardware that had previously deployed a RHEL
  Overcloud-controller which places metadata on the disk as a legitimate
  source, that cloud-init looks at by default.  When the newly enlisted
  node appeared it had the name of "overcloud-controller-0" vs. maas-
  enlist, pulled from the disk metadata which had overridden MAAS'
  metadata.  Commissioning continually failed on all of the nodes until
  the disk metadata was manually removed (KVM boot Ubuntu ISO, rm -f
  data or dd zeros to disk).

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1582323/+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 1596690] Re: restoring from datasource without dsmode causes stacktrace

[Scott Moser]

fixed in trunk at revno 1246

** Changed in: cloud-init
   Importance: Undecided => High

** Changed in: cloud-init
   Status: New => Fix Committed

** Changed in: cloud-init
 Assignee: (unassigned) => Scott Moser (smoser)

** Changed in: cloud-init (Ubuntu)
   Importance: Undecided => High

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => Fix Committed

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Xenial)
 Assignee: (unassigned) => Scott Moser (smoser)

** Changed in: cloud-init (Ubuntu)
 Assignee: (unassigned) => Scott Moser (smoser)

** Tags removed: verification-needed
** Tags added: verification-done

-- 
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/1596690

Title:
  restoring from datasource without dsmode causes stacktrace

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released

Bug description:
  On reboot, if cloud-init found a cached /var/lib/cloud/instance/obj.pkl it 
would restore from it.
  If that class did not have a 'dsmode', then main would stack trace like:
  | "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 530, in 
status_wrapper
  | ret = functor(name, args)
  |   File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 247, in 
main_init
  | if mode == sources.DSMODE_NETWORK and init.datasource.dsmode != mode:
  | AttributeError: 'DataSourceAzureNet' object has no attribute 'dsmode'

  This would affect upgrade and reboot on any datasource that did not
  have a dsmode previously.

  That list is
cloudinit/sources/DataSourceAzure.py
cloudinit/sources/DataSourceBigstep.py
cloudinit/sources/DataSourceCloudStack.py
cloudinit/sources/DataSourceDigitalOcean.py
cloudinit/sources/DataSourceEc2.py
cloudinit/sources/DataSourceGCE.py
cloudinit/sources/DataSourceMAAS.py
cloudinit/sources/DataSourceNone.py
cloudinit/sources/DataSourceOVF.py
cloudinit/sources/DataSourceSmartOS.py

  The non-broken datasources then were the ones that previously had a dsmode:
cloudinit/sources/DataSourceAltCloud.py
cloudinit/sources/DataSourceCloudSigma.py
cloudinit/sources/DataSourceConfigDrive.py
cloudinit/sources/DataSourceNoCloud.py
cloudinit/sources/DataSourceOpenNebula.py
cloudinit/sources/DataSourceOpenStack.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1596690/+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 1599260] Re: Old version information should be configurable

[Steve Martinelli]

adding ironic since they have the same problem:
http://developer.openstack.org/api-ref/baremetal/index.html

** 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 OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1599260

Title:
  Old version information should be configurable

Status in Ironic:
  New
Status in OpenStack Identity (keystone):
  Confirmed
Status in oslosphinx:
  New

Bug description:
  Have a look at http://developer.openstack.org//api-
  ref/identity/v2/index.html

  The version information here makes no sense, we do not have links to
  old documents for the api at all. These links should not appear. Can
  we make them configurable, please?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ironic/+bug/1599260/+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 1494841] Re: nova-manage vm list active

[OpenStack Infra]

Reviewed:  https://review.openstack.org/339219
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=5a5b06fb24fc6e392eb5381f1348e475f1302e1e
Submitter: Jenkins
Branch:master

commit 5a5b06fb24fc6e392eb5381f1348e475f1302e1e
Author: Matt Riedemann 
Date:   Thu Jul 7 16:07:53 2016 -0400

Deprecate nova-manage vm list command

The nova-manage vm command is replaced with the nova list command
in python-novaclient, and has been for a long time.

As of microversion 2.3, the fields that are output from
nova-manage vm list are all covered in the REST API for showing server
details, which can also be used via the --fields option of the nova
list command. The nova list command also allows filtering by host.

This sets the timer for deprecation and then removal in Ocata.

Change-Id: Ibce8c3deb24a16019b721d3b91640ca342ae541b
Closes-Bug: #1494841


** Changed in: nova
   Status: In Progress => Fix Released

-- 
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/1494841

Title:
  nova-manage vm list active

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  Pre Kilo, nova-manage vm list only showed active vm's. This was useful
  for ops to track down what vms were on which hosts, etc.

  After kilo, all the deleted ones are returned too. This is ok, but its
  much slower to query if you |grep active.

  There needs to be an --active flag or something to filter on the db
  side for better performance.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1494841/+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 1590133] Re: help text for cpu_allocation_ratio is wrong

[OpenStack Infra]

Reviewed:  https://review.openstack.org/329593
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=ff10a41de910bb4c577d39cb6f2a73ac97ab6b3b
Submitter: Jenkins
Branch:master

commit ff10a41de910bb4c577d39cb6f2a73ac97ab6b3b
Author: Sivasathurappan Radhakrishnan 
Date:   Tue Jun 14 17:29:43 2016 +

Improve help text for allocation_ratio_opts

This commit adds additional help text to allocation_
ratio_opts
Blueprint centralize-config-options-newton
Closes-Bug: #1590133
Change-Id: I4654bb26184a2a993aab9476e5d303f5f00803e0


** Changed in: nova
   Status: In Progress => Fix Released

-- 
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/1590133

Title:
  help text for cpu_allocation_ratio is wrong

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  In stable/mitaka in resource_tracker.py the help text for the
  cpu_allocation_ratio config option reads in part:

   'NOTE: This can be set per-compute, or if set to 0.0, the value '
   'set on the scheduler node(s) will be used '
   'and defaulted to 16.0'),

  However, there is no longer any value set on the scheduler node(s).
  They use the per-compute-node value set in resource_tracker.py.

  Instead, if the value is 0.0 then ComputeNode._from_db_object() will
  convert the value to 16.0.  This ensures that the scheduler filters
  see a value of 16.0 by default.

  In Newton the plan appears to be to change the default value to an
  explicit 16.0 (and presumably updating the help text) but that doesn't
  help the already-released Mitaka code.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1590133/+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 1601842] [NEW] stack.sh fails on devstack with python3

[Inessa Vasilevskaya]

Public bug reported:

Steps to reproduce:

1. localrc with python 3 enabled (the precise one I used 
http://paste.openstack.org/show/529714/)
2. run stack.sh

Script terminated with the following error:
(17:32:46) ivasilevskaya: CRITICAL keystone [-] ImportError: No module named 
'memcache' (more logs here http://paste.openstack.org/show/529680/).

memcache is present in pip3.4 installed package list and can be
successfully imported manually.

I made some blind guesses what might be wrong (never configured python3
devstack before), after installing libpython3-dev the error transfered
to http://paste.openstack.org/show/529710/.

** Affects: keystone
 Importance: Undecided
 Status: New

-- 
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/1601842

Title:
  stack.sh fails on devstack with python3

Status in OpenStack Identity (keystone):
  New

Bug description:
  Steps to reproduce:

  1. localrc with python 3 enabled (the precise one I used 
http://paste.openstack.org/show/529714/)
  2. run stack.sh

  Script terminated with the following error:
  (17:32:46) ivasilevskaya: CRITICAL keystone [-] ImportError: No module named 
'memcache' (more logs here http://paste.openstack.org/show/529680/).

  memcache is present in pip3.4 installed package list and can be
  successfully imported manually.

  I made some blind guesses what might be wrong (never configured
  python3 devstack before), after installing libpython3-dev the error
  transfered to http://paste.openstack.org/show/529710/.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1601842/+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 1599359] Re: Typo in contribute.rst

[Anindita Das]

** Changed in: neutron
   Status: Fix Committed => 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/1599359

Title:
  Typo in contribute.rst

Status in neutron:
  Fix Released

Bug description:
  The following lines are missing ',':
  1. However every case is different and you are invited to seek guidance from 
Neutron core reviewers about what steps to follow.
  2. However they are still quite happy to answer any questions you might have 
about vulnerability management for your own projects even if they're not part 
of that set. Feel free to reach out to the VMT in public or in private.
  3. If a commercial distribution such as Red Hat is redistributing a 
vulnerable version of your software then they may assign one anyway even if you 
don't request one yourself.

  Wrong use of article before "enforced":
  1. The following strategies are recommendations only, since third-party CI 
testing is not a enforced requirement

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1599359/+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 1601822] [NEW] remotefs.RsyncDriver() should use utils.safe_ip_format()

[Alexey I. Froloff]

Public bug reported:

IPv6 address literal should be wrapped in square brackets when calling
rsync:

Resize error: not able to execute ssh command: Unexpected error while running 
command.
Command: rsync --archive --relative --no-implied-dirs 
/tmp/tmpo_wpSz/./var/lib/nova/instances/fd7c6610-cf13-42e0-826c-3b4eb2494465 
fd4b:cafe:dead:beef::bad:f00d:/
Exit code: 255
Stdout: u''
Stderr: u'ssh: Could not resolve hostname fd4b: Name or service not 
known\r\nrsync: connection unexpectedly closed (0 bytes received so far) 
[sender]\nrsync error: unexplained error (code 255) at io.c(226) 
[sender=3.1.0]\n'

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

Title:
  remotefs.RsyncDriver() should use utils.safe_ip_format()

Status in OpenStack Compute (nova):
  New

Bug description:
  IPv6 address literal should be wrapped in square brackets when calling
  rsync:

  Resize error: not able to execute ssh command: Unexpected error while running 
command.
  Command: rsync --archive --relative --no-implied-dirs 
/tmp/tmpo_wpSz/./var/lib/nova/instances/fd7c6610-cf13-42e0-826c-3b4eb2494465 
fd4b:cafe:dead:beef::bad:f00d:/
  Exit code: 255
  Stdout: u''
  Stderr: u'ssh: Could not resolve hostname fd4b: Name or service not 
known\r\nrsync: connection unexpectedly closed (0 bytes received so far) 
[sender]\nrsync error: unexplained error (code 255) at io.c(226) 
[sender=3.1.0]\n'

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1601822/+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 1369465] Re: nova resize doesn't resize(extend) rbd disk files when using rbd disk backend

[Corey Bryant]

** Also affects: cloud-archive/liberty
   Importance: Undecided
   Status: New

** Also affects: nova (Ubuntu Wily)
   Importance: Undecided
   Status: New

** Changed in: cloud-archive/liberty
   Status: New => Triaged

** Changed in: nova (Ubuntu Wily)
   Status: New => Triaged

** Changed in: cloud-archive/liberty
   Importance: Undecided => Medium

** Changed in: cloud-archive
   Importance: Undecided => Medium

** Changed in: nova (Ubuntu Wily)
   Importance: Undecided => Medium

-- 
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/1369465

Title:
  nova resize doesn't resize(extend) rbd disk files when using rbd disk
  backend

Status in Ubuntu Cloud Archive:
  Fix Released
Status in Ubuntu Cloud Archive liberty series:
  Triaged
Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) liberty series:
  Fix Committed
Status in nova package in Ubuntu:
  Fix Released
Status in nova source package in Wily:
  Triaged

Bug description:
  [Impact]

   * Not able to resize rbd backed disk image.

  [Test Case]

  1 - boot an instance with rbd backed disk image
  2 - resize it
  3 - log into the VM
  4 - the disk is not enlarged without this patch

  [Regression Potential]

   * None

  
  tested with nova trunk commit eb860c2f219b79e4f4c5984415ee433145197570

  Configured Nova to use rbd disk backend

  nova.conf

  [libvirt]
  images_type=rbd

  instances booted successfully and instance disks are in rbd pools,
  when perform a nova resize  to an existing instance,  memory and CPU
  changed to be new flavors but instance disks size doesn't change

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1369465/+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 1600774] [NEW] lookup DNS and use it before creating a new one

[Rossella Sblendido]

Public bug reported:

In some deployment DNS is already pre-populated for every IP. To make
Neutron use this DNS name, the attribute dns_name needs to be filled. It
would be more straightforward to provide in Neutron a way to fill
automatically this dns_name, doing a reverse DNS lookup.

** Affects: neutron
 Importance: Wishlist
 Status: Confirmed

** Changed in: neutron
   Status: New => Confirmed

** Changed in: neutron
   Importance: Undecided => Wishlist

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1600774

Title:
  lookup DNS  and use it before creating a new one

Status in neutron:
  Confirmed

Bug description:
  In some deployment DNS is already pre-populated for every IP. To make
  Neutron use this DNS name, the attribute dns_name needs to be filled.
  It would be more straightforward to provide in Neutron a way to fill
  automatically this dns_name, doing a reverse DNS lookup.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1600774/+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 1508442] Re: LOG.warn is deprecated

[Swapnil Kulkarni]

** No longer affects: neutron

** Changed in: nova
   Status: In Progress => Fix Released

** No longer affects: blazar

** Changed in: zaqar
   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/1508442

Title:
  LOG.warn is deprecated

Status in anvil:
  In Progress
Status in Aodh:
  Fix Released
Status in Astara:
  Fix Released
Status in Barbican:
  Fix Released
Status in bilean:
  Fix Released
Status in Ceilometer:
  Fix Released
Status in cloud-init:
  In Progress
Status in cloudkitty:
  Fix Released
Status in congress:
  Fix Released
Status in Designate:
  Fix Released
Status in django-openstack-auth:
  Fix Released
Status in django-openstack-auth-kerberos:
  In Progress
Status in DragonFlow:
  Fix Released
Status in ec2-api:
  Fix Released
Status in Evoque:
  In Progress
Status in Freezer:
  In Progress
Status in gce-api:
  Fix Released
Status in Gnocchi:
  Fix Released
Status in heat:
  Fix Released
Status in heat-cfntools:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in KloudBuster:
  Fix Released
Status in kolla:
  Fix Released
Status in Magnum:
  Fix Released
Status in Manila:
  Fix Released
Status in Mistral:
  In Progress
Status in networking-arista:
  In Progress
Status in networking-calico:
  In Progress
Status in networking-cisco:
  In Progress
Status in networking-fujitsu:
  Fix Released
Status in networking-odl:
  In Progress
Status in networking-ofagent:
  In Progress
Status in networking-plumgrid:
  In Progress
Status in networking-powervm:
  Fix Released
Status in networking-vsphere:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in nova-powervm:
  Fix Released
Status in nova-solver-scheduler:
  In Progress
Status in octavia:
  Fix Released
Status in openstack-ansible:
  Fix Released
Status in oslo.cache:
  Fix Released
Status in Packstack:
  Fix Released
Status in python-dracclient:
  Fix Released
Status in python-magnumclient:
  Fix Released
Status in RACK:
  In Progress
Status in python-watcherclient:
  In Progress
Status in OpenStack Search (Searchlight):
  Fix Released
Status in shaker:
  Fix Released
Status in Solum:
  Fix Released
Status in tempest:
  Fix Released
Status in tripleo:
  Fix Released
Status in trove-dashboard:
  Fix Released
Status in watcher:
  Fix Released
Status in zaqar:
  Fix Released

Bug description:
  LOG.warn is deprecated in Python 3 [1] . But it still used in a few
  places, non-deprecated LOG.warning should be used instead.

  Note: If we are using logger from oslo.log, warn is still valid [2],
  but I agree we can switch to LOG.warning.

  [1]https://docs.python.org/3/library/logging.html#logging.warning
  [2]https://github.com/openstack/oslo.log/blob/master/oslo_log/log.py#L85

To manage notifications about this bug go to:
https://bugs.launchpad.net/anvil/+bug/1508442/+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 1512207] Re: Fix usage of assertions

[Swapnil Kulkarni]

** Changed in: group-based-policy
   Status: In Progress => Invalid

** No longer affects: os-testr

** No longer affects: python-barbicanclient

** No longer affects: tempest

** No longer affects: blazar

** No longer affects: magnum

-- 
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/1512207

Title:
  Fix usage of assertions

Status in Aodh:
  Fix Released
Status in Barbican:
  Fix Released
Status in Cinder:
  Invalid
Status in congress:
  Fix Released
Status in Cue:
  Fix Released
Status in Glance:
  Won't Fix
Status in Group Based Policy:
  Invalid
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in kuryr:
  Fix Released
Status in Manila:
  Fix Released
Status in Murano:
  Fix Released
Status in neutron:
  Fix Released
Status in OpenStack Compute (nova):
  Invalid
Status in OpenStack Health:
  Invalid
Status in os-brick:
  Fix Released
Status in os-net-config:
  Fix Released
Status in oslo.cache:
  Fix Released
Status in oslo.messaging:
  Fix Released
Status in Packstack:
  Fix Released
Status in python-ceilometerclient:
  Fix Released
Status in python-novaclient:
  Fix Released
Status in python-openstackclient:
  Fix Released
Status in OpenStack SDK:
  Fix Released
Status in Rally:
  Fix Released
Status in requests-mock:
  Won't Fix
Status in Sahara:
  Fix Released
Status in shaker:
  Fix Released
Status in Solum:
  Fix Released
Status in Stackalytics:
  Fix Released
Status in OpenStack Object Storage (swift):
  In Progress
Status in OpenStack DBaaS (Trove):
  Fix Released
Status in Vitrage:
  Fix Released
Status in watcher:
  Fix Released
Status in zaqar:
  Fix Released

Bug description:
  Manila  should use the specific assertion:

self.assertIsTrue/False(observed)

  instead of the generic assertion:

self.assertEqual(True/False, observed)

To manage notifications about this bug go to:
https://bugs.launchpad.net/aodh/+bug/1512207/+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 1280522] Re: Replace assertEqual(None, *) with assertIsNone in tests

[Swapnil Kulkarni]

** Changed in: stackalytics
   Status: In Progress => Fix Released

-- 
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/1280522

Title:
  Replace assertEqual(None, *) with assertIsNone in tests

Status in Anchor:
  Fix Released
Status in bifrost:
  Fix Released
Status in Blazar:
  In Progress
Status in Cinder:
  Fix Released
Status in congress:
  Fix Released
Status in Designate:
  Fix Released
Status in dox:
  New
Status in Glance:
  Fix Released
Status in glance_store:
  Fix Released
Status in heat:
  Fix Released
Status in heat-cfntools:
  Fix Released
Status in Heat Translator:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-python-agent:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in keystoneauth:
  Fix Released
Status in kolla-mesos:
  Fix Released
Status in Manila:
  Fix Released
Status in networking-cisco:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in octavia:
  Fix Released
Status in ooi:
  Fix Released
Status in os-client-config:
  Fix Released
Status in python-barbicanclient:
  Fix Released
Status in python-ceilometerclient:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-congressclient:
  Fix Released
Status in python-cueclient:
  Fix Released
Status in python-designateclient:
  Fix Released
Status in python-glanceclient:
  Fix Released
Status in python-heatclient:
  Fix Released
Status in python-ironicclient:
  Fix Released
Status in python-manilaclient:
  Fix Released
Status in python-neutronclient:
  Fix Released
Status in python-openstackclient:
  Fix Released
Status in OpenStack SDK:
  Fix Released
Status in python-swiftclient:
  Fix Released
Status in python-troveclient:
  Fix Released
Status in Python client library for Zaqar:
  Fix Released
Status in Sahara:
  Fix Released
Status in Solum:
  Fix Released
Status in Stackalytics:
  Fix Released
Status in tempest:
  Fix Released
Status in OpenStack DBaaS (Trove):
  Fix Released
Status in tuskar:
  Fix Released
Status in watcher:
  Fix Released
Status in zaqar:
  Fix Released
Status in designate package in Ubuntu:
  Fix Released
Status in python-tuskarclient package in Ubuntu:
  Fix Committed

Bug description:
  Replace assertEqual(None, *) with assertIsNone in tests to have
  more clear messages in case of failure.

To manage notifications about this bug go to:
https://bugs.launchpad.net/anchor/+bug/1280522/+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 1600752] [NEW] Admin user can its subnet interface into other tenant's router stealthily.

[tianqing]

Public bug reported:

1. login horizon dashboard with admin user
2. in the admin->system->network->router page, admin can add its own subnet 
interface into any router.

But the user can not see the interface his net topology.

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

Title:
  Admin user can its subnet interface into other tenant's router
  stealthily.

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  1. login horizon dashboard with admin user
  2. in the admin->system->network->router page, admin can add its own subnet 
interface into any router.

  But the user can not see the interface his net topology.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1600752/+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 1600721] Re: [mitaka]create firewall which assocation with router will be failed

[zhanghaixia]

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

Title:
  [mitaka]create firewall which assocation with router will be failed

Status in neutron:
  Invalid

Bug description:
  Traceback (most recent call last):
  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/site-packages/neutron/api/v2/resource.py", line 84, in 
resource

  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource result
  = method(request=request, **args)

  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
  "/usr/lib/python2.7/site-packages/neutron/api/v2/base.py", line 410,
  in create

  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource return
  self._create(request, body, **kwargs)

  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
  "/usr/lib/python2.7/site-packages/oslo_db/api.py", line 148, in
  wrapper

  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource
  ectxt.value = e.inner_exc

  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
  "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220,
  in __exit__

  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource
  self.force_reraise()

  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
  "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196,
  in force_reraise

  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource
  six.reraise(self.type_, self.value, self.tb)

  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
  "/usr/lib/python2.7/site-packages/oslo_db/api.py", line 138, in
  wrapper

  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource return
  f(*args, **kwargs)

  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
  "/usr/lib/python2.7/site-packages/neutron/api/v2/base.py", line 521,
  in _create

  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource obj =
  do_create(body)

  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
  "/usr/lib/python2.7/site-packages/neutron/api/v2/base.py", line 503,
  in do_create

  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource
  request.context, reservation.reservation_id)

  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
  "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220,
  in __exit__

  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource
  self.force_reraise()

  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
  "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196,
  in force_reraise

  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource
  six.reraise(self.type_, self.value, self.tb)

  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
  "/usr/lib/python2.7/site-packages/neutron/api/v2/base.py", line 496,
  in do_create

  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource return
  obj_creator(request.context, **kwargs)

  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
  "/usr/lib/python2.7/site-
  packages/neutron_fwaas/services/firewall/fwaas_plugin.py", line 236,
  in create_firewall

  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource
  firewall['firewall']['tenant_id'], context, firewall)

  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
  "/usr/lib/python2.7/site-
  packages/neutron_fwaas/services/firewall/fwaas_plugin.py", line 229,
  in _get_routers_for_create_firewall

  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource
  self.validate_firewall_routers_not_in_use(context, router_ids)

  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
  "/usr/lib/python2.7/site-packages/oslo_log/helpers.py", line 46, in
  wrapper

  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource return
  method(*args, **kwargs)

  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
  "/usr/lib/python2.7/site-
  packages/neutron_fwaas/db/firewall/firewall_router_insertion_db.py",
  line 75, in validate_firewall_routers_not_in_use

  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource
  FirewallRouterAssociation.fw_id != fwid).all()

  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
  "/usr/lib64/python2.7/site-packages/sqlalchemy/orm/query.py", line
  2588, in all

  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource return
  list(self)

  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
  "/usr/lib64/python2.7/site-packages/sqlalchemy/orm/query.py", line
  2736, in __iter__

  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource return
  self._execute_and_instances(context)

  2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
  "/usr/lib64/python2.7/site-p

[Yahoo-eng-team] [Bug 1596976] Re: optimize refresh firewall on ipset member update

[venkata anil]

*** This bug is a duplicate of bug 1371435 ***
https://bugs.launchpad.net/bugs/1371435

** This bug has been marked a duplicate of bug 1371435
   Remove unnecessary iptables reload when L2 agent enable ipset

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1596976

Title:
  optimize refresh firewall  on ipset member update

Status in neutron:
  New

Bug description:
  Before the ipset, a port was creating explicit firewall rule to other 
ports(member of the same security group) i.e
  port's firewall rules without ipset
  -A neutron-openvswi-i92605eaf-b -s 192.168.83.17/32 -j RETURN
  -A neutron-openvswi-i92605eaf-b -s 192.168.83.18/32 -j RETURN
  -A neutron-openvswi-i92605eaf-b -s 192.168.83.15/32 -j RETURN
  with ipset
  -A neutron-openvswi-i92605eaf-b -m set –match-set ${ipset_name} src -j RETURN

  With ipset, when a new port is up on remote ovs agent, then on local
  ovs agent, only kernel ipset has to be updated and no need to update
  any firewall rules. When port on remote agent is deleted, then it has
  to be deleted from local agent's ipset, and corresponding connection
  tracking entries has to deleted. In both the above scenarios, ovs
  shouldn't update firewall rules.

   But current implementation is trying to update firewall rules(this
  will result in removing all in-memory firewall rules and again
  creating them, but still no iptable rules are updated on system). This
  is consuming lot of agent's time. We can optimize this by avoid
  updating in-memory firewall rules for this scenario, and make firewall
  refresh for securitygroup-member-update faster.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1596976/+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 1280105] Re: urllib/urllib2 is incompatible for python 3

[Swapnil Kulkarni]

** Changed in: magnum
   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/1280105

Title:
  urllib/urllib2  is incompatible for python 3

Status in Ceilometer:
  Fix Released
Status in Cinder:
  In Progress
Status in Fuel for OpenStack:
  Fix Released
Status in Glance:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Magnum:
  Fix Released
Status in Manila:
  Fix Committed
Status in neutron:
  Fix Released
Status in python-troveclient:
  Fix Released
Status in refstack:
  Fix Released
Status in Sahara:
  Fix Released
Status in tacker:
  In Progress
Status in tempest:
  Fix Released
Status in OpenStack DBaaS (Trove):
  In Progress
Status in Zuul:
  In Progress

Bug description:
  urllib/urllib2  is incompatible for python 3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1280105/+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 1280522] Re: Replace assertEqual(None, *) with assertIsNone in tests

[Swapnil Kulkarni]

** Changed in: python-openstacksdk
   Status: In Progress => Fix Released

-- 
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/1280522

Title:
  Replace assertEqual(None, *) with assertIsNone in tests

Status in Anchor:
  Fix Released
Status in bifrost:
  Fix Released
Status in Blazar:
  In Progress
Status in Cinder:
  Fix Released
Status in congress:
  Fix Released
Status in Designate:
  Fix Released
Status in dox:
  New
Status in Glance:
  Fix Released
Status in glance_store:
  Fix Released
Status in heat:
  Fix Released
Status in heat-cfntools:
  Fix Released
Status in Heat Translator:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-python-agent:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in keystoneauth:
  Fix Released
Status in kolla-mesos:
  Fix Released
Status in Manila:
  Fix Released
Status in networking-cisco:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in octavia:
  Fix Released
Status in ooi:
  Fix Released
Status in os-client-config:
  Fix Released
Status in python-barbicanclient:
  Fix Released
Status in python-ceilometerclient:
  Fix Released
Status in python-cinderclient:
  Fix Released
Status in python-congressclient:
  Fix Released
Status in python-cueclient:
  Fix Released
Status in python-designateclient:
  Fix Released
Status in python-glanceclient:
  Fix Released
Status in python-heatclient:
  Fix Released
Status in python-ironicclient:
  Fix Released
Status in python-manilaclient:
  Fix Released
Status in python-neutronclient:
  Fix Released
Status in python-openstackclient:
  Fix Released
Status in OpenStack SDK:
  Fix Released
Status in python-swiftclient:
  Fix Released
Status in python-troveclient:
  Fix Released
Status in Python client library for Zaqar:
  Fix Released
Status in Sahara:
  Fix Released
Status in Solum:
  Fix Released
Status in Stackalytics:
  In Progress
Status in tempest:
  Fix Released
Status in OpenStack DBaaS (Trove):
  Fix Released
Status in tuskar:
  Fix Released
Status in watcher:
  Fix Released
Status in zaqar:
  Fix Released
Status in designate package in Ubuntu:
  Fix Released
Status in python-tuskarclient package in Ubuntu:
  Fix Committed

Bug description:
  Replace assertEqual(None, *) with assertIsNone in tests to have
  more clear messages in case of failure.

To manage notifications about this bug go to:
https://bugs.launchpad.net/anchor/+bug/1280522/+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 1600733] [NEW] MechanismDriverError/sqlite3.OperationalError: no such table: ml2_geneve_allocations

[Darren Hoyland]

Public bug reported:

The Openstack Interoperability Lab hit this error: "OperationalError:
(sqlite3.OperationalError) no such table: ml2_geneve_allocations [SQL:
u'SELECT ml2_geneve_allocations.geneve_vni AS
ml2_geneve_allocations_geneve_vni, ml2_geneve_allocations.allocated AS
ml2_geneve_allocations_allocated \nFROM ml2_geneve_allocations']"

This manifests itself in the console as "NeutronClientException:
500-{u'NeutronError': {u'message': u'create_subnet_postcommit failed.',
u'type': u'MechanismDriverError', u'detail': u''}}"

We hit this whilst using the following components:

Block Storage cinder-iscsi
Compute   nova-kvm
Database  mysql
Image Storage glance-swift
Openstack Version mitaka
SDN   neutron-calico
Ubuntu Versionxenial 

The following traceback was found in /neutron-api_*/var/log/neutron
/neutron-server.log


2016-07-10 00:45:36.418 15401 ERROR neutron.service [-] Unrecoverable error: 
please check log for details.
2016-07-10 00:45:36.418 15401 ERROR neutron.service Traceback (most recent call 
last):
2016-07-10 00:45:36.418 15401 ERROR neutron.service   File 
"/usr/lib/python2.7/dist-packages/neutron/service.py", line 107, in serve_wsgi
2016-07-10 00:45:36.418 15401 ERROR neutron.service service.start()
2016-07-10 00:45:36.418 15401 ERROR neutron.service   File 
"/usr/lib/python2.7/dist-packages/neutron/service.py", line 80, in start
2016-07-10 00:45:36.418 15401 ERROR neutron.service self.wsgi_app = 
_run_wsgi(self.app_name)
2016-07-10 00:45:36.418 15401 ERROR neutron.service   File 
"/usr/lib/python2.7/dist-packages/neutron/service.py", line 234, in _run_wsgi
2016-07-10 00:45:36.418 15401 ERROR neutron.service app = 
config.load_paste_app(app_name)
2016-07-10 00:45:36.418 15401 ERROR neutron.service   File 
"/usr/lib/python2.7/dist-packages/neutron/common/config.py", line 290, in 
load_paste_app
2016-07-10 00:45:36.418 15401 ERROR neutron.service app = 
loader.load_app(app_name)
2016-07-10 00:45:36.418 15401 ERROR neutron.service   File 
"/usr/lib/python2.7/dist-packages/oslo_service/wsgi.py", line 353, in load_app
2016-07-10 00:45:36.418 15401 ERROR neutron.service return 
deploy.loadapp("config:%s" % self.config_path, name=name)
2016-07-10 00:45:36.418 15401 ERROR neutron.service   File 
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 247, in 
loadapp
2016-07-10 00:45:36.418 15401 ERROR neutron.service return loadobj(APP, 
uri, name=name, **kw)
2016-07-10 00:45:36.418 15401 ERROR neutron.service   File 
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 272, in 
loadobj
2016-07-10 00:45:36.418 15401 ERROR neutron.service return context.create()
2016-07-10 00:45:36.418 15401 ERROR neutron.service   File 
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 710, in create
2016-07-10 00:45:36.418 15401 ERROR neutron.service return 
self.object_type.invoke(self)
2016-07-10 00:45:36.418 15401 ERROR neutron.service   File 
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 144, in invoke
2016-07-10 00:45:36.418 15401 ERROR neutron.service **context.local_conf)
2016-07-10 00:45:36.418 15401 ERROR neutron.service   File 
"/usr/lib/python2.7/dist-packages/paste/deploy/util.py", line 55, in fix_call
2016-07-10 00:45:36.418 15401 ERROR neutron.service val = callable(*args, 
**kw)
2016-07-10 00:45:36.418 15401 ERROR neutron.service   File 
"/usr/lib/python2.7/dist-packages/paste/urlmap.py", line 28, in urlmap_factory
2016-07-10 00:45:36.418 15401 ERROR neutron.service app = 
loader.get_app(app_name, global_conf=global_conf)
2016-07-10 00:45:36.418 15401 ERROR neutron.service   File 
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 350, in 
get_app
2016-07-10 00:45:36.418 15401 ERROR neutron.service name=name, 
global_conf=global_conf).create()
2016-07-10 00:45:36.418 15401 ERROR neutron.service   File 
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 710, in create
2016-07-10 00:45:36.418 15401 ERROR neutron.service return 
self.object_type.invoke(self)
2016-07-10 00:45:36.418 15401 ERROR neutron.service   File 
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 144, in invoke
2016-07-10 00:45:36.418 15401 ERROR neutron.service **context.local_conf)
2016-07-10 00:45:36.418 15401 ERROR neutron.service   File 
"/usr/lib/python2.7/dist-packages/paste/deploy/util.py", line 55, in fix_call
2016-07-10 00:45:36.418 15401 ERROR neutron.service val = callable(*args, 
**kw)
2016-07-10 00:45:36.418 15401 ERROR neutron.service   File 
"/usr/lib/python2.7/dist-packages/neutron/auth.py", line 71, in pipeline_factory
2016-07-10 00:45:36.418 15401 ERROR neutron.service app = 
loader.get_app(pipeline[-1])
2016-07-10 00:45:36.418 15401 ERROR neutron.service   File 
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 350, in 
get_app
2016-07-10 00:45:36.418 15401 ERROR neutron.service nam

[Yahoo-eng-team] [Bug 1576713] Re: Network metadata fails to state correct mtu

[Dr. Jens Rosenboom]

** Changed in: nova/mitaka
   Status: Fix Committed => Fix Released

-- 
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/1576713

Title:
  Network metadata fails to state correct mtu

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) mitaka series:
  Fix Released

Bug description:
  Scenario:

  Instance is booted on Neutron tenant network with ML2 OVS driver and
  encapsulation. The MTU for that network is automatically calculated as
  1450. Instance has --config-drive=true set.

  Result:

  In /openstack/latest/network_data.json we get:

   "links": [{"ethernet_mac_address": "fa:16:3e:36:96:c8", "mtu": null,
  "type": "ovs", "id": "tapb989c3aa-5c", "vif_id": "b989c3aa-5c1f-
  4d2b-8711-b96c66604902"}]

  Expected:

  Have "mtu": "1450" instead.

  Environment:

  OpenStack Mitaka on Ubuntu 16.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1576713/+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 1600725] [NEW] add groupv3 controller unit test code in master branch

[huyupeng]

Public bug reported:

add groupv3 controller unit test code in master branch

** Affects: keystone
 Importance: Undecided
 Assignee: huyupeng (huyp)
 Status: New

** Changed in: keystone
 Assignee: (unassigned) => huyupeng (huyp)

-- 
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/1600725

Title:
  add groupv3 controller unit test code in master branch

Status in OpenStack Identity (keystone):
  New

Bug description:
  add groupv3 controller unit test code in master branch

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1600725/+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 1600721] [NEW] [mitaka]create firewall which assocation with router will be failed

[zhanghaixia]

Public bug reported:

Traceback (most recent call last):
2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/site-packages/neutron/api/v2/resource.py", line 84, in 
resource

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource result =
method(request=request, **args)

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
"/usr/lib/python2.7/site-packages/neutron/api/v2/base.py", line 410, in
create

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource return
self._create(request, body, **kwargs)

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
"/usr/lib/python2.7/site-packages/oslo_db/api.py", line 148, in wrapper

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource
ectxt.value = e.inner_exc

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in
__exit__

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource
self.force_reraise()

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in
force_reraise

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource
six.reraise(self.type_, self.value, self.tb)

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
"/usr/lib/python2.7/site-packages/oslo_db/api.py", line 138, in wrapper

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource return
f(*args, **kwargs)

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
"/usr/lib/python2.7/site-packages/neutron/api/v2/base.py", line 521, in
_create

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource obj =
do_create(body)

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
"/usr/lib/python2.7/site-packages/neutron/api/v2/base.py", line 503, in
do_create

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource
request.context, reservation.reservation_id)

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in
__exit__

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource
self.force_reraise()

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in
force_reraise

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource
six.reraise(self.type_, self.value, self.tb)

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
"/usr/lib/python2.7/site-packages/neutron/api/v2/base.py", line 496, in
do_create

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource return
obj_creator(request.context, **kwargs)

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
"/usr/lib/python2.7/site-
packages/neutron_fwaas/services/firewall/fwaas_plugin.py", line 236, in
create_firewall

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource
firewall['firewall']['tenant_id'], context, firewall)

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
"/usr/lib/python2.7/site-
packages/neutron_fwaas/services/firewall/fwaas_plugin.py", line 229, in
_get_routers_for_create_firewall

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource
self.validate_firewall_routers_not_in_use(context, router_ids)

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
"/usr/lib/python2.7/site-packages/oslo_log/helpers.py", line 46, in
wrapper

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource return
method(*args, **kwargs)

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
"/usr/lib/python2.7/site-
packages/neutron_fwaas/db/firewall/firewall_router_insertion_db.py",
line 75, in validate_firewall_routers_not_in_use

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource
FirewallRouterAssociation.fw_id != fwid).all()

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
"/usr/lib64/python2.7/site-packages/sqlalchemy/orm/query.py", line 2588,
in all

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource return
list(self)

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
"/usr/lib64/python2.7/site-packages/sqlalchemy/orm/query.py", line 2736,
in __iter__

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource return
self._execute_and_instances(context)

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
"/usr/lib64/python2.7/site-packages/sqlalchemy/orm/query.py", line 2751,
in _execute_and_instances

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource result =
conn.execute(querycontext.statement, self._params)

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource   File
"/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line
914, in execute

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2.resource return
meth(self, multiparams, params)

2016-07-11 04:03:54.033 3785 ERROR neutron.api.v2

[Yahoo-eng-team] [Bug 1586268] Re: Unit test: self.assertNotEqual in unit.test_base.BaseTest.test_eq does not work in PY2

[Ji.Wei]

** No longer affects: glance

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1586268

Title:
  Unit test: self.assertNotEqual in  unit.test_base.BaseTest.test_eq
  does not work in PY2

Status in Ceilometer:
  New
Status in daisycloud-core:
  New
Status in heat:
  New
Status in OpenStack Dashboard (Horizon):
  New
Status in keystonemiddleware:
  New
Status in neutron:
  New
Status in OpenStack Compute (nova):
  In Progress
Status in python-barbicanclient:
  New
Status in python-ceilometerclient:
  In Progress
Status in python-cinderclient:
  Fix Released
Status in python-congressclient:
  In Progress
Status in python-glanceclient:
  In Progress
Status in python-heatclient:
  Fix Released
Status in python-keystoneclient:
  In Progress
Status in python-manilaclient:
  New
Status in python-muranoclient:
  Fix Released
Status in python-novaclient:
  Fix Released
Status in python-smaugclient:
  In Progress
Status in python-swiftclient:
  New
Status in python-troveclient:
  In Progress
Status in OpenStack Object Storage (swift):
  New
Status in tempest:
  New

Bug description:
  Version: master(20160527)

  In case cinderclient.tests.unit.test_base.BaseTest.test_eq 
self.assertNotEqual does not work.
  Class base.Resource defines __eq__() built-in function, but does not define 
__ne__() built-in function, so self.assertEqual works but self.assertNotEqual 
does not work at all in this test case.

  steps:
  1 Clone code of python-cinderclient from master.
  2 Modify the case of unit test: cinderclient/tests/unit/test_base.py
    line50--line62.
  def test_eq(self):
  # Two resources with same ID: never equal if their info is not equal
  r1 = base.Resource(None, {'id': 1, 'name': 'hi'})
  r2 = base.Resource(None, {'id': 1, 'name': 'hello'})
  self.assertNotEqual(r1, r2)

  # Two resources with same ID: equal if their info is equal
  r1 = base.Resource(None, {'id': 1, 'name': 'hello'})
  r2 = base.Resource(None, {'id': 1, 'name': 'hello'})
  # self.assertEqual(r1, r2)
  self.assertNotEqual(r1, r2)

  # Two resoruces of different types: never equal
  r1 = base.Resource(None, {'id': 1})
  r2 = volumes.Volume(None, {'id': 1})
  self.assertNotEqual(r1, r2)

  # Two resources with no ID: equal if their info is equal
  r1 = base.Resource(None, {'name': 'joe', 'age': 12})
  r2 = base.Resource(None, {'name': 'joe', 'age': 12})
  # self.assertEqual(r1, r2)
  self.assertNotEqual(r1, r2)

     Modify self.assertEqual(r1, r2) to self.assertNotEqual(r1, r2).

  3 Run unit test, and return success.

  After that, I make a test:

  class Resource(object):
  def __init__(self, person):
  self.person = person

  def __eq__(self, other):
  return self.person == other.person

  r1 = Resource("test")
  r2 = Resource("test")
  r3 = Resource("test_r3")
  r4 = Resource("test_r4")

  print r1 != r2
  print r1 == r2
  print r3 != r4
  print r3 == r4

  The result is :
  True
  True
  True
  False

  Whether r1 is precisely the same to r2 or not, self.assertNotEqual(r1,
  r2) return true.So I think self.assertNotEqual doesn't work at all in
  python2 and  should be modified.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1586268/+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 1600710] [NEW] Failed to launch instance in vcenter configured with non default port

[Johnson koil raj]

Public bug reported:

Description
===

One of my environment I have configured my vCenter to listen on non
default port ( eg: 1400 ). By default vCenter will listen on 443. In
this Instances are failed to boot. From the log I came to copy of images
from glance to datastore which happens through the ESXi servers fails
because ESXi servers are Listening on default port. Image copying method
creating the URL which uses the port of vCenter not the ESXi host.

Steps to reproduce
==
* Configure vCenter to listen on port 1400 ( other than 443 )
* Boot a instance

Expected result
===
Instance launch should be successful 

Actual result
=
But instance launch will fail with below error

2016-07-01 05:10:04.480 29447 DEBUG oslo_vmware.rw_handles [req-
e12d5f3a-fa5f-44f3-9c5b-7350a9760c20 33f0250cb0db41a8a17bf240b81406b7
63fcf407f5bc492996c3a9afc93f7b42] Creating HTTP connection to write to
file with size = 18808832 and URL =
https://1.1.2.3:1400/folder/vmware_temp/d22ddfc3-7fbd-
42b9-82e5-f45b0e7313ec/8b33e6a9-2da4-46df-8c7a-71d700e4/tmp-
sparse.vmdk?dsName=ds-37&dcPath=ha-datacenter. _create_write_connection
/opt/stack/venv/nova-20160628T001806Z/lib/python2.7/site-
packages/oslo_vmware/rw_handles.py:126



2016-07-01 05:12:11.757 29447 ERROR nova.compute.manager 
[req-e12d5f3a-fa5f-44f3-9c5b-7350a9760c20 33f0250cb0db41a8a17bf240b81406b7 
63fcf407f5bc492996c3a9afc93f7b42] [instance: 
d7f6f84c-024d-481e-b41d-5f416ff94305] Instance failed to spawn
2016-07-01 05:12:11.757 29447 ERROR nova.compute.manager [instance: 
d7f6f84c-024d-481e-b41d-5f416ff94305] Traceback (most recent call last):
2016-07-01 05:12:11.757 29447 ERROR nova.compute.manager [instance: 
d7f6f84c-024d-481e-b41d-5f416ff94305]   File 
"/opt/stack/venv/nova-20160628T001806Z/lib/python2.7/site-packages/nova/compute/manager.py",
 line 2220, in _build_resources
2016-07-01 05:12:11.757 29447 ERROR nova.compute.manager [instance: 
d7f6f84c-024d-481e-b41d-5f416ff94305] yield resources
2016-07-01 05:12:11.757 29447 ERROR nova.compute.manager [instance: 
d7f6f84c-024d-481e-b41d-5f416ff94305]   File 
"/opt/stack/venv/nova-20160628T001806Z/lib/python2.7/site-packages/nova/compute/manager.py",
 line 2066, in _build_and_run_instance
2016-07-01 05:12:11.757 29447 ERROR nova.compute.manager [instance: 
d7f6f84c-024d-481e-b41d-5f416ff94305] block_device_info=block_device_info)
2016-07-01 05:12:11.757 29447 ERROR nova.compute.manager [instance: 
d7f6f84c-024d-481e-b41d-5f416ff94305]   File 
"/opt/stack/venv/nova-20160628T001806Z/lib/python2.7/site-packages/nova/virt/vmwareapi/hp_driver.py",
 line 66, in spawn
2016-07-01 05:12:11.757 29447 ERROR nova.compute.manager [instance: 
d7f6f84c-024d-481e-b41d-5f416ff94305] power_on=False)
2016-07-01 05:12:11.757 29447 ERROR nova.compute.manager [instance: 
d7f6f84c-024d-481e-b41d-5f416ff94305]   File 
"/opt/stack/venv/nova-20160628T001806Z/lib/python2.7/site-packages/nova/virt/vmwareapi/vmops.py",
 line 751, in spawn
2016-07-01 05:12:11.757 29447 ERROR nova.compute.manager [instance: 
d7f6f84c-024d-481e-b41d-5f416ff94305] self._fetch_image_if_missing(context, 
vi)
2016-07-01 05:12:11.757 29447 ERROR nova.compute.manager [instance: 
d7f6f84c-024d-481e-b41d-5f416ff94305]   File 
"/opt/stack/venv/nova-20160628T001806Z/lib/python2.7/site-packages/nova/virt/vmwareapi/vmops.py",
 line 614, in _fetch_image_if_missing
2016-07-01 05:12:11.757 29447 ERROR nova.compute.manager [instance: 
d7f6f84c-024d-481e-b41d-5f416ff94305] image_fetch(context, vi, 
tmp_image_ds_loc)
2016-07-01 05:12:11.757 29447 ERROR nova.compute.manager [instance: 
d7f6f84c-024d-481e-b41d-5f416ff94305]   File 
"/opt/stack/venv/nova-20160628T001806Z/lib/python2.7/site-packages/nova/virt/vmwareapi/vmops.py",
 line 405, in _fetch_image_as_file
2016-07-01 05:12:11.757 29447 ERROR nova.compute.manager [instance: 
d7f6f84c-024d-481e-b41d-5f416ff94305] cookies=cookies)
2016-07-01 05:12:11.757 29447 ERROR nova.compute.manager [instance: 
d7f6f84c-024d-481e-b41d-5f416ff94305]   File 
"/opt/stack/venv/nova-20160628T001806Z/lib/python2.7/site-packages/nova/virt/vmwareapi/images.py",
 line 236, in fetch_image
2016-07-01 05:12:11.757 29447 ERROR nova.compute.manager [instance: 
d7f6f84c-024d-481e-b41d-5f416ff94305] host, port, dc_name, ds_name, 
cookies, file_path, file_size)
2016-07-01 05:12:11.757 29447 ERROR nova.compute.manager [instance: 
d7f6f84c-024d-481e-b41d-5f416ff94305]   File 
"/opt/stack/venv/nova-20160628T001806Z/lib/python2.7/site-packages/oslo_vmware/rw_handles.py",
 line 272, in __init__
2016-07-01 05:12:11.757 29447 ERROR nova.compute.manager [instance: 
d7f6f84c-024d-481e-b41d-5f416ff94305] ssl_thumbprint=thumbprint)
2016-07-01 05:12:11.757 29447 ERROR nova.compute.manager [instance: 
d7f6f84c-024d-481e-b41d-5f416ff94305]   File 
"/opt/stack/venv/nova-20160628T001806Z/lib/python2.7/site-packages/oslo_vmware/rw_handles.py",
 line 142, in _create_write_connection
2016-07-01 05:1

[Yahoo-eng-team] [Bug 1600708] [NEW] Update ‘--max-kbps’ and ‘--max-burst-kbps’ parameter to 2147483648 or greater than 2147483648 using qos-bandwidth-limit-rule-update command，Neutron server thrown a

[xiewj]

Public bug reported:

In Mitaka,
Update ‘--max-kbps’ and ‘--max-burst-kbps’ parameter to 2147483648 or greater 
than 2147483648 using qos-bandwidth-limit-rule-update command，
Neutron server thrown an exception "DBDataError: (pymysql.err.DataError) (1264, 
u"Out of range value for column 'max_kbps' at row 1")"

[root@devstack218 devstack]# neutron qos-bandwidth-limit-rule-update 
11a8e94a-92d0-41b5-a7bf-36f2a55f4573 bw-limiter --max-kbps 2147483648
Request Failed: internal server error while processing your request.
Neutron server returns request_ids: ['req-82a00cf8-3efd-4c82-830e-8295560866f0']


[root@devstack218 devstack]# neutron qos-bandwidth-limit-rule-update 
11a8e94a-92d0-41b5-a7bf-36f2a55f4573 bw-limiter --max-burst-kbps 2147483648
Request Failed: internal server error while processing your request.
Neutron server returns request_ids: ['req-52fd2986-5076-42c4-b564-10d58984f87f']
[root@devstack218 devstack]# 

The detail info of Neutron-Server,please see
http://paste.openstack.org/show/529609/

** Affects: neutron
 Importance: Undecided
 Assignee: QunyingRan (ran-qunying)
 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/1600708

Title:
  Update ‘--max-kbps’ and ‘--max-burst-kbps’ parameter to 2147483648 or
  greater than 2147483648 using qos-bandwidth-limit-rule-update
  command，Neutron server thrown an exception

Status in neutron:
  New

Bug description:
  In Mitaka,
  Update ‘--max-kbps’ and ‘--max-burst-kbps’ parameter to 2147483648 or greater 
than 2147483648 using qos-bandwidth-limit-rule-update command，
  Neutron server thrown an exception "DBDataError: (pymysql.err.DataError) 
(1264, u"Out of range value for column 'max_kbps' at row 1")"

  [root@devstack218 devstack]# neutron qos-bandwidth-limit-rule-update 
11a8e94a-92d0-41b5-a7bf-36f2a55f4573 bw-limiter --max-kbps 2147483648
  Request Failed: internal server error while processing your request.
  Neutron server returns request_ids: 
['req-82a00cf8-3efd-4c82-830e-8295560866f0']

  
  [root@devstack218 devstack]# neutron qos-bandwidth-limit-rule-update 
11a8e94a-92d0-41b5-a7bf-36f2a55f4573 bw-limiter --max-burst-kbps 2147483648
  Request Failed: internal server error while processing your request.
  Neutron server returns request_ids: 
['req-52fd2986-5076-42c4-b564-10d58984f87f']
  [root@devstack218 devstack]# 

  The detail info of Neutron-Server,please see
  http://paste.openstack.org/show/529609/

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1600708/+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 1600701] [NEW] RHEL7.2 OS Login dialog has been covered by cloud-init output logs

[Sibiao Luo]

Public bug reported:

RHEL7.2 OS Login dialog has been covered by cloud-init output logs until
user press the "Enter" keyboard, Login appear only after return has been
pressed, this affect the user experience.

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

Title:
  RHEL7.2 OS Login dialog has been covered by cloud-init output logs

Status in cloud-init:
  New

Bug description:
  RHEL7.2 OS Login dialog has been covered by cloud-init output logs
  until user press the "Enter" keyboard, Login appear only after return
  has been pressed, this affect the user experience.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1600701/+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 1600698] [NEW] no network info will lead to valueerror

[jichenjc]

Public bug reported:

liberty release, when the instance don't have any network info ,seems
master has same issue

[root@xcat ~] # nova show fc76de3f-a022-45b4-8998-9dd9bf4bd1e4
+--+--+
| Property | Value  
  |
+--+--+
|  network |
  |
| OS-DCF:diskConfig| MANUAL 
  |
| OS-EXT-AZ:availability_zone  | 1234   
  |


[root@xcat ~] # neutron net-list
+--++---+
| id   | name   | subnets   
|
+--++---+
| eff8994b-8663-4104-b349-332ee6c3195f | singleflat | 
3c17106c-5b26-4406-88f6-da8bf2c38e64 192.168.222.0/24 |


2016-07-11 07:04:03.532 35598 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 142, 
in _dispatch_and_reply
2016-07-11 07:04:03.532 35598 ERROR oslo_messaging.rpc.dispatcher 
executor_callback))
2016-07-11 07:04:03.532 35598 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 186, 
in _dispatch
2016-07-11 07:04:03.532 35598 ERROR oslo_messaging.rpc.dispatcher 
executor_callback)
2016-07-11 07:04:03.532 35598 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 129, 
in _do_dispatch
2016-07-11 07:04:03.532 35598 ERROR oslo_messaging.rpc.dispatcher result = 
func(ctxt, **new_args)
2016-07-11 07:04:03.532 35598 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/nova/exception.py", line 89, in wrapped
2016-07-11 07:04:03.532 35598 ERROR oslo_messaging.rpc.dispatcher payload)
2016-07-11 07:04:03.532 35598 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 195, in __exit__
2016-07-11 07:04:03.532 35598 ERROR oslo_messaging.rpc.dispatcher 
six.reraise(self.type_, self.value, self.tb)
2016-07-11 07:04:03.532 35598 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/nova/exception.py", line 72, in wrapped
2016-07-11 07:04:03.532 35598 ERROR oslo_messaging.rpc.dispatcher return 
f(self, context, *args, **kw)
2016-07-11 07:04:03.532 35598 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 350, in 
decorated_function
2016-07-11 07:04:03.532 35598 ERROR oslo_messaging.rpc.dispatcher 
LOG.warning(msg, e, instance=instance)
2016-07-11 07:04:03.532 35598 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 195, in __exit__
2016-07-11 07:04:03.532 35598 ERROR oslo_messaging.rpc.dispatcher 
six.reraise(self.type_, self.value, self.tb)
2016-07-11 07:04:03.532 35598 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 323, in 
decorated_function
2016-07-11 07:04:03.532 35598 ERROR oslo_messaging.rpc.dispatcher return 
function(self, context, *args, **kwargs)
2016-07-11 07:04:03.532 35598 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 400, in 
decorated_function
2016-07-11 07:04:03.532 35598 ERROR oslo_messaging.rpc.dispatcher return 
function(self, context, *args, **kwargs)
2016-07-11 07:04:03.532 35598 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 378, in 
decorated_function
2016-07-11 07:04:03.532 35598 ERROR oslo_messaging.rpc.dispatcher 
kwargs['instance'], e, sys.exc_info())
2016-07-11 07:04:03.532 35598 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 195, in __exit__
2016-07-11 07:04:03.532 35598 ERROR oslo_messaging.rpc.dispatcher 
six.reraise(self.type_, self.value, self.tb)
2016-07-11 07:04:03.532 35598 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 366, in 
decorated_function
2016-07-11 07:04:03.532 35598 ERROR oslo_messaging.rpc.dispatcher return 
function(self, context, *args, **kwargs)
2016-07-11 07:04:03.532 35598 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2522, in 
start_instance
2016-07-11 07:04:03.532 35598 ERROR oslo_messaging.rpc.dispatcher   

[Yahoo-eng-team] [Bug 1600697] [NEW] Using VMware NSXv driver, when update the port with specified address pair, got exception

[Yang Yu]

Public bug reported:

yangyubj@yangyubj-virtual-machine:~$ neutron port-update 
26d1a5e7-a745-4f6a-b965-bb33709a8a23 --allowed-address-pair 
ip_address=10.0.0.0/8
Request 
https://10.155.20.92/api/4.0/services/spoofguard/spoofguardpolicy-9?action=approve
 is Bad, response 
The value 10.0.0.0/8 for vm 
(01985390-cf9a-4cf7-bad3-2f164edc45d9) - Network adapter 1 is invalid. Valid 
value should be 
{2}220core-services
Neutron server returns request_ids: ['req-98cc6835-a2a2-43b3-bde4-b6aa47e313e1']


The root cause is the NSXv can not support cidr 10.0.0.0/8

** Affects: neutron
 Importance: Undecided
 Assignee: Yang Yu (yuyangbj)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) => Yang Yu (yuyangbj)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1600697

Title:
  Using VMware NSXv driver, when update the port with specified address
  pair, got exception

Status in neutron:
  New

Bug description:
  yangyubj@yangyubj-virtual-machine:~$ neutron port-update 
26d1a5e7-a745-4f6a-b965-bb33709a8a23 --allowed-address-pair 
ip_address=10.0.0.0/8
  Request 
https://10.155.20.92/api/4.0/services/spoofguard/spoofguardpolicy-9?action=approve
 is Bad, response 
  The value 10.0.0.0/8 for vm 
(01985390-cf9a-4cf7-bad3-2f164edc45d9) - Network adapter 1 is invalid. Valid 
value should be 
{2}220core-services
  Neutron server returns request_ids: 
['req-98cc6835-a2a2-43b3-bde4-b6aa47e313e1']

  
  The root cause is the NSXv can not support cidr 10.0.0.0/8

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