[Yahoo-eng-team] [Bug 1655833] [NEW] The error response for placement API doesn't work with i18n

[Alex Xu]

Public bug reported:

In most of placement API code, we just put the exception into the error message 
like this
https://github.com/openstack/nova/blob/d57ce1dda839865c8060458760fa27dbbd7e2aee/nova/api/openstack/placement/handlers/resource_class.py#L108

This is equal to str(exc). This won't works for i18n.

We can use "exc.format_message()"

** Affects: nova
 Importance: Undecided
 Status: New


** Tags: placement

** Tags added: placement

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

Title:
  The error response for placement API doesn't work with i18n

Status in OpenStack Compute (nova):
  New

Bug description:
  In most of placement API code, we just put the exception into the error 
message like this
  
https://github.com/openstack/nova/blob/d57ce1dda839865c8060458760fa27dbbd7e2aee/nova/api/openstack/placement/handlers/resource_class.py#L108

  This is equal to str(exc). This won't works for i18n.

  We can use "exc.format_message()"

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1655833/+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 1600418] Re: Flavor name edit should trim for white spaces and compare with other flavor names

[OpenStack Infra]

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

commit 23c482b941b53243b9f57c5707d266870c3c2225
Author: Yakup Adakli 
Date:   Mon Nov 28 15:28:44 2016 +0300

Strip whitespace added to flavor name in create and update flavor.

Change-Id: I633a4124615ca0c6cfe6b103e117e3ebd6d79241
Closes-Bug: #1600418


** Changed in: horizon
   Status: Triaged => 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/1600418

Title:
  Flavor name edit should trim for white spaces and compare with other
  flavor names

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  When editing the flavor name from horizon
  1. Enter new flavor name which is same as one of the existing flavor name
  2. Make sure that you have entered leading and trailing spaces
  Try saving this flavor and it fails with error.
  we should ideally strip the flavor name before making any comparison.

  As a specific example
  1. Create flavor with name test1
  2. Create flavor with name test2
  3. Edit flavor test2
  4. When editing try giving name "test1"(new name same as one of the 
existing flavor and leading and trailing spaces in the new name)
  5. Save the flavor
  6. we get an error that 'Unable to modify test1'.

  Now we were modifying test2 and not test1. Error should ideally say
  that the flavor with name 'test1' already exists(as the case is if we
  try the same from CLI)

  One more unexpected behavior that happens is that 'test2' in above
  case is removed from the flavor listing page in UI

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1600418/+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 1311582] Re: resource usage for storage components shows no results

[Richard Jones]

Ceilometer isn't part of Horizon any longer.

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

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

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

Title:
  resource usage for storage components shows no results

Status in OpenStack Dashboard (Horizon):
  Invalid

Bug description:
  when I try to view storage resources in horizon's "resource usage" tab we get 
no data available message. 
  looking at horizon log I see that we are getting an error but can't find 
anything in ceilometer to suggest why we fail to show the info. 

  HTTP/0.9 200

  
  Error response
  
  
  Error response
  Error code 400.
  Message: Bad request syntax ('GET /v2/meters/image.update 
/statistics?q.field=project_idq.field=timestampq.field=timestampq.op=eqq.op=geq.op=leq.type=q.type=q.type=q.value=18b1ac6dfd3f4235a420d136662c7062q.value=2014-04-16+10%3A10%3A11.121506q.value=2014-04-23+10%3A10%3A11.121522period=1512
 HTTP/1.1').
  Error code explanation: 400 = Bad request syntax or unsupported method.
  

  
  2014-04-23 10:10:11,267 2351 DEBUG ceilometerclient.common.http 
  HTTP/0.9 200 

  
  Error response
  
  
  Error response
  Error code 400.
  Message: Bad request syntax ('GET /v2/meters/image.update 
/statistics?q.field=project_idq.field=timestampq.field=timestampq.op=eqq.op=geq.op=leq.type=q.type=q.type=q.value=c3178ebef2c24d1b9a045bd67483a83cq.value=2014-04-16+10%3A10%3A11.121506q.value=2014-04-23+10%3A10%3A11.121522period=1512
 HTTP/1.1').
  Error code explanation: 400 = Bad request syntax or unsupported method.
  

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1311582/+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 1655810] [NEW] firewall-policy-insert-rule iptables rule does not take effect

[fisher]

Public bug reported:

when execute neutron firewall-policy-insert-rule ** command，The
configuration takes effect，but the iptables rule doesn't takes effect on
the computer node.

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

Title:
  firewall-policy-insert-rule iptables rule does not take effect

Status in neutron:
  New

Bug description:
  when execute neutron firewall-policy-insert-rule ** command，The
  configuration takes effect，but the iptables rule doesn't takes effect
  on the computer node.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1655810/+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 1655785] [NEW] Use the session loader in keystoneauth1 for designate

[OpenStack Infra]

Public bug reported:

https://review.openstack.org/416048
Dear bug triager. This bug was created since a commit was marked with DOCIMPACT.
Your project "openstack/neutron" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

commit b38f1cb1f737dede90f3df74f3515d63c357fa30
Author: Gyorgy Szombathelyi 
Date:   Mon Dec 19 13:58:10 2016 +0100

Use the session loader in keystoneauth1 for designate

Using the session loader has the benefit of compatibility with
settings in other sections (like keystone_authtoken), and the
ability to use client certs and setting the timeout. This changes
the designate.ca_cert setting to designate.cafile, but the former
is added as a deprecated option, so existing config files will work.

DocImpact
ca_cert in [designate] is deprecated, use cafile instead.

Change-Id: I9f2173b02af5c3929a96ef8c773d587e9b673d62

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: doc 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/1655785

Title:
  Use the session loader in keystoneauth1 for designate

Status in neutron:
  New

Bug description:
  https://review.openstack.org/416048
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/neutron" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

  commit b38f1cb1f737dede90f3df74f3515d63c357fa30
  Author: Gyorgy Szombathelyi 
  Date:   Mon Dec 19 13:58:10 2016 +0100

  Use the session loader in keystoneauth1 for designate
  
  Using the session loader has the benefit of compatibility with
  settings in other sections (like keystone_authtoken), and the
  ability to use client certs and setting the timeout. This changes
  the designate.ca_cert setting to designate.cafile, but the former
  is added as a deprecated option, so existing config files will work.
  
  DocImpact
  ca_cert in [designate] is deprecated, use cafile instead.
  
  Change-Id: I9f2173b02af5c3929a96ef8c773d587e9b673d62

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1655785/+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 1649446] Re: Non-Admin Access to Revocation Events

[Jeremy Stanley]

Consensus seems to be that this was intentional behavior, but worth
changing (as evidenced by a subsequent fix to master). Given that and
the lack of stable branch backports, I'm going to treat this as a
security hardening opportunity. If there is fierce disagreement favoring
backports and an official advisory, we can revisit the classification at
that time.

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

** Information type changed from Public Security to Public

** Tags added: security

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

Title:
  Non-Admin Access to Revocation Events

Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  With the default Keystone policy any authed user can list all revocation 
events for the cluster:
  https://github.com/openstack/keystone/blob/master/etc/policy.json#L179

  This can be done by directly calling the API as such:
  curl -g -i -X GET http://localhost/identity/v3/OS-REVOKE/events -H "Accept: 
application/json" -H "X-Auth-Token: "

  and this will provide you with a normal revocation event list (see
  attachment).

  This will allow a user to over time collect a list of user_ids and
  project_ids. The project_ids aren't particularly useful, but the
  user_ids can be used to lock people of of their accounts. Or if rate
  limiting is not setup (a bad idea), or somehow bypassed, would allow
  someone to brute force access to those ids.

  Knowing the ids is no worse than knowing the usernames, but as a non-
  admin you shouldn't have access to such a list anyway.

  It is also worth noting that OpenStack policy files are rife with
  these blank policy rules, not just Keystone. Some are safe and
  intended to be accessible by any authed user, others are checked at
  the code layer, but there may be other rules that are unsafe to expose
  to any authed user and as such should actually default to
  "rule:admin_required" or something other than blank.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1649446/+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 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection)

[Xing Yang]

In Cinder, the following drivers are using six.moves.http_client, which
on python 2.7 I believe calls httplib:

   Location: cinder/cinder/volume/drivers/blockbridge.py:149
   Location: cinder/cinder/volume/drivers/cloudbyte/cloudbyte.py:116
   Location: cinder/cinder/volume/drivers/prophetstor/dplcommon.py:102
   Location: cinder/cinder/volume/drivers/prophetstor/dplcommon.py:124
   Location: cinder/cinder/volume/drivers/qnap.py:814
   Location: cinder/cinder/volume/drivers/zadara.py:238

See reference of six.moves.http_client calling httplib here:
https://pythonhosted.org/six/

Re-opening the bug.

** Changed in: cinder
   Status: Invalid => Triaged

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

Title:
  Some server-side 'SSL' communication fails to check certificates (use
  of HTTPSConnection)

Status in Cinder:
  Triaged
Status in OpenStack Identity (keystone):
  Fix Released
Status in neutron:
  Fix Released
Status in oslo.vmware:
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix
Status in OpenStack Security Notes:
  Fix Released
Status in python-keystoneclient:
  Fix Released
Status in OpenStack Object Storage (swift):
  Invalid

Bug description:
  Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection
  objects. In Python 2.x those do not perform CA checks so client
  connections are vulnerable to MiM attacks.

  """
  The following files use httplib.HTTPSConnection :
  keystone/middleware/s3_token.py
  keystone/middleware/ec2_token.py
  keystone/common/bufferedhttp.py
  vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py

  AFAICT HTTPSConnection does not validate server certificates and
  should be avoided. This is fixed in Python 3, however in 2.X no
  validation occurs. I suspect this is also applicable to most OpenStack
  modules that make HTTPS client calls.

  Similar problems were found in ovirt:
  https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533)

  With solutions for ovirt:
  http://gerrit.ovirt.org/#/c/7209/
  http://gerrit.ovirt.org/#/c/7249/
  """

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1188189/+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 1655494] Re: Newton scheduler clients should keep trying to report

[OpenStack Infra]

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

commit bbf9b431ee26e4064278e58bf9c177de48e8719a
Author: Dan Smith 
Date:   Tue Jan 10 13:49:19 2017 -0800

Make placement client keep trying to connect

In Newton, placement is optional and computes will stop even trying
to connect to placement when they encounter an error or missing
configuration. We really want them to keep trying so that enabling
the service pre-upgrade does not require restarting all computes
to start filling data.

This patch removes the auto-disable logic and replaces it with a
limited, but persistent warning to the logs about the required
nature of placement for the upgrade. If we had messaged the upcoming
requirement better, I think we could have been less chatty here.
However, we know that it's not been received, so this patch periodically
re-emits the warning and mentions the upgrade specifically.

Closes-Bug: #1655494
Change-Id: Ie6387afeb239a20d39c00f519e8288f3b3a5e9cb


** Changed in: nova
   Status: Confirmed => 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/1655494

Title:
  Newton scheduler clients should keep trying to report

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) newton series:
  New

Bug description:
  Newton scheduler clients will stop reporting any time they encounter a
  setup-related error, which isn't very operator-friendly for the ocata
  upgrade process.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1655494/+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 1655013] Re: double assignment of user to group does not give error

[Lance Bragstad]

Hi Martin,

I agree that the feedback could be a bit better when a user is already a
member of a specific group, but I'm not sure an error would be the best
approach. Since we already return a 204 No Content response when a user
is added to a group (or added when they are already a member). If we
returned a 4XX response code for the same situation in the v3 API, we be
breaking backwards compatibility.

The good thing is the operation to add users to groups is idempotent
even if they are already a member of the group. There is a
openstackclient command to check membership based on the user and the
group:

> openstack group add user accounting bob
bob added to group accounting   


  > openstack group add user accounting bob
bob added to group accounting
> openstack group contains user accounting bob
bob in group accounting


Do you have tooling around the client that is expecting an error when a user 
already belongs to a group?

I'm going to mark this as invalid for now since we won't be able to
change the response code unless we introduce a microversion of the API
(which keystone doesn't have support for yet) or we introduce a new API
entirely (i.e. v4).

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

Title:
  double assignment of user to group does not give error

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  Double group assignment.
  [student@ctrl ~(teacher)]$ openstack --os-project-name headoffice group add 
user newGroup student62
  student62 added to group newGroup
  [lab3]:teacher@
  [student@ctrl ~(teacher)]$ openstack --os-project-name headoffice group add 
user newGroup student62
  student62 added to group newGroup
  [lab3]:teacher@

  The second line should give an error that the user is already assigned
  to a group.

  I checked the database keystone.user_group_membership and there is
  only assignment there (happy that the problem was not that bad).

  [student@ctrl ~(teacher)]$ openstack --version
  openstack 2.3.0
  [lab3]:teacher@
  [student@ctrl ~(teacher)]$ uname -a
  Linux ctrl.lab3.stack 3.10.0-514.2.2.el7.x86_64 #1 SMP Tue Dec 6 23:06:41 UTC 
2016 x86_64 x86_64 x86_64 GNU/Linux
  [lab3]:teacher@
  [student@ctrl ~(teacher)]$ cat /etc/*-release
  CentOS Linux release 7.3.1611 (Core)
  NAME="CentOS Linux"
  VERSION="7 (Core)"
  ID="centos"
  ID_LIKE="rhel fedora"
  VERSION_ID="7"
  PRETTY_NAME="CentOS Linux 7 (Core)"
  ANSI_COLOR="0;31"
  CPE_NAME="cpe:/o:centos:centos:7"
  HOME_URL="https://www.centos.org/;
  BUG_REPORT_URL="https://bugs.centos.org/;

  CENTOS_MANTISBT_PROJECT="CentOS-7"
  CENTOS_MANTISBT_PROJECT_VERSION="7"
  REDHAT_SUPPORT_PRODUCT="centos"
  REDHAT_SUPPORT_PRODUCT_VERSION="7"

  CentOS Linux release 7.3.1611 (Core)
  CentOS Linux release 7.3.1611 (Core)
  [lab3]:teacher@

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1655013/+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 1655761] [NEW] Resource Provider generation update missing

[Ed Leafe]

Public bug reported:

Most of the methods that increase the generation for a resource provider
also update the value of `generation` in the object that calls it, but
there is one place where it was missing: the _set_allocations() method
of the AllocationList class. This resulted in some ResourceProvider
references having stale values for `generation`, which would cause a
ConcurrentUpdateDetected exception to be raised.

** Affects: nova
 Importance: Undecided
 Assignee: Ed Leafe (ed-leafe)
 Status: In Progress


** Tags: placement

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

Title:
  Resource Provider generation update missing

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  Most of the methods that increase the generation for a resource
  provider also update the value of `generation` in the object that
  calls it, but there is one place where it was missing: the
  _set_allocations() method of the AllocationList class. This resulted
  in some ResourceProvider references having stale values for
  `generation`, which would cause a ConcurrentUpdateDetected exception
  to be raised.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1655761/+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 1655727] [NEW] Improve compatibility with eventlet 0.20.1

[Dirk Mueller]

Public bug reported:

Eventlet 0.20.x added support for green version of subprocess, which
however causes an issue with glance tests:

glance.tests.functional.db.test_registry.TestRegistryDriver.test_image_create_bad_property
--

Captured traceback:
~~~
Traceback (most recent call last):
  File "glance/tests/functional/db/test_registry.py", line 74, in setUp
super(TestRegistryDriver, self).setUp()
  File "glance/tests/functional/db/base.py", line 95, in setUp
super(TestDriver, self).setUp()
  File "glance/tests/functional/db/test_registry.py", line 62, in setUp
api_version=2)
  File "glance/tests/functional/__init__.py", line 765, in start_with_retry
**kwargs)
  File "glance/tests/functional/__init__.py", line 148, in start
self.create_database()
  File "glance/tests/functional/__init__.py", line 230, in create_database
expect_exit=True)
  File "glance/tests/utils.py", line 318, in execute
result = process.communicate()
  File "/usr/lib64/python2.7/subprocess.py", line 800, in communicate
return self._communicate(input)
  File "/usr/lib64/python2.7/subprocess.py", line 1417, in _communicate
stdout, stderr = self._communicate_with_poll(input)
  File "/usr/lib64/python2.7/subprocess.py", line 1447, in 
_communicate_with_poll
poller = select.poll()
AttributeError: 'module' object has no attribute 'poll'

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

Title:
  Improve compatibility with eventlet 0.20.1

Status in Glance:
  New

Bug description:
  Eventlet 0.20.x added support for green version of subprocess, which
  however causes an issue with glance tests:

  
glance.tests.functional.db.test_registry.TestRegistryDriver.test_image_create_bad_property
  
--

  Captured traceback:
  ~~~
  Traceback (most recent call last):
File "glance/tests/functional/db/test_registry.py", line 74, in setUp
  super(TestRegistryDriver, self).setUp()
File "glance/tests/functional/db/base.py", line 95, in setUp
  super(TestDriver, self).setUp()
File "glance/tests/functional/db/test_registry.py", line 62, in setUp
  api_version=2)
File "glance/tests/functional/__init__.py", line 765, in 
start_with_retry
  **kwargs)
File "glance/tests/functional/__init__.py", line 148, in start
  self.create_database()
File "glance/tests/functional/__init__.py", line 230, in create_database
  expect_exit=True)
File "glance/tests/utils.py", line 318, in execute
  result = process.communicate()
File "/usr/lib64/python2.7/subprocess.py", line 800, in communicate
  return self._communicate(input)
File "/usr/lib64/python2.7/subprocess.py", line 1417, in _communicate
  stdout, stderr = self._communicate_with_poll(input)
File "/usr/lib64/python2.7/subprocess.py", line 1447, in 
_communicate_with_poll
  poller = select.poll()
  AttributeError: 'module' object has no attribute 'poll'

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1655727/+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 1655718] [NEW] nav bar intermittently does not display

[Eric Peterson]

Public bug reported:

>From time to time, the left hand nav bar does not display correctly.

This seems to occur a bit more frequently when you switch projects with
different roles (admin to _member_ or back and fort), and also occurs
when horizon is provided by several backend servers (behind a load
balancer).

I'm suspecting that this only occurs with several horizon nodes behind a
LB, and could be a timing or caching issue - but it's not 100% clear
when this does or does not occur.

Rob had said he would look into this more.

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

Title:
  nav bar intermittently does not display

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  From time to time, the left hand nav bar does not display correctly.

  This seems to occur a bit more frequently when you switch projects
  with different roles (admin to _member_ or back and fort), and also
  occurs when horizon is provided by several backend servers (behind a
  load balancer).

  I'm suspecting that this only occurs with several horizon nodes behind
  a LB, and could be a timing or caching issue - but it's not 100% clear
  when this does or does not occur.

  Rob had said he would look into this more.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1655718/+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 1649341] Re: Undercloud upgrade fails with "Cell mappings are not created, but required for Ocata"

[Alex Schultz]

** Changed in: tripleo
   Status: Fix Released => 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/1649341

Title:
  Undercloud upgrade fails with "Cell mappings are not created, but
  required for Ocata"

Status in OpenStack Compute (nova):
  Fix Released
Status in puppet-nova:
  Fix Released
Status in tripleo:
  In Progress

Bug description:
  Trying to upgrade with recent trunk nova and puppet-nova gives this
  error:

  Notice: /Stage[main]/Nova::Db::Sync_api/Exec[nova-db-sync-api]/returns: 
error: Cell mappings are not created, but required for Ocata. Please run 
nova-manage db simple_cell_setup before continuing.
  Error: /usr/bin/nova-manage  api_db sync returned 1 instead of one of [0]
  Error: /Stage[main]/Nova::Db::Sync_api/Exec[nova-db-sync-api]/returns: change 
from notrun to 0 failed: /usr/bin/nova-manage  api_db sync returned 1 instead 
of one of [0]

  
  Debugging manually gives:

  $ sudo /usr/bin/nova-manage  api_db sync
  error: Cell mappings are not created, but required for Ocata. Please run 
nova-manage db simple_cell_setup before continuing.

  
  but...

  $ sudo nova-manage db simple_cell_setup
  usage: nova-manage db [-h]


{archive_deleted_rows,null_instance_uuid_scan,online_data_migrations,sync,version}
...
  nova-manage db: error: argument action: invalid choice: 'simple_cell_setup' 
(choose from 'archive_deleted_rows', 'null_instance_uuid_scan', 
'online_data_migrations', 'sync', 'version')

  
  I tried adding openstack-nova* to the delorean-current whitelist, but with 
the latest nova packages there still appears to be this mismatch.

  [stack@instack /]$ rpm -qa | grep nova
  openstack-nova-conductor-15.0.0-0.20161212155146.909410c.el7.centos.noarch
  python-nova-15.0.0-0.20161212155146.909410c.el7.centos.noarch
  openstack-nova-scheduler-15.0.0-0.20161212155146.909410c.el7.centos.noarch
  puppet-nova-10.0.0-0.20161211003757.09b9f7b.el7.centos.noarch
  python2-novaclient-6.0.0-0.20161003181629.25117fa.el7.centos.noarch
  openstack-nova-api-15.0.0-0.20161212155146.909410c.el7.centos.noarch
  openstack-nova-cert-15.0.0-0.20161212155146.909410c.el7.centos.noarch
  openstack-nova-common-15.0.0-0.20161212155146.909410c.el7.centos.noarch
  openstack-nova-compute-15.0.0-0.20161212155146.909410c.el7.centos.noarch

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1649341/+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 1655710] [NEW] Query parameter validation using json schema - error messages

[Diana Clarke]

Public bug reported:

A mechanism to validate query parameters using json schema was added in
the following series:

https://review.openstack.org/#/q/topic:bp/consistent-query-
parameters-validation

The resulting error messages aren't very user friendly though. For
example, if you pass an invalid limit to os-keypairs list, you used to
get a custom message rather than the obscure message generated by json
schema.

Before:

webob.exc.HTTPBadRequest: Invalid input received: limit must be an
integer

After:

nova.exception.ValidationError: Invalid input for query parameters
0. Value: abc. u'abc' does not match '^[0-9]*$'

The exception raised also changed, which may be problematic for API
consumers.

We probably need another layer to transform these generated messages
into something more user friendly, and perhaps consider raising
HTTPBadRequest again with the nicer error message.

** Affects: nova
 Importance: Medium
 Status: Confirmed


** Tags: api

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

Title:
  Query parameter validation using json schema - error messages

Status in OpenStack Compute (nova):
  Confirmed

Bug description:
  A mechanism to validate query parameters using json schema was added
  in the following series:

  https://review.openstack.org/#/q/topic:bp/consistent-query-
  parameters-validation

  The resulting error messages aren't very user friendly though. For
  example, if you pass an invalid limit to os-keypairs list, you used to
  get a custom message rather than the obscure message generated by json
  schema.

  Before:

  webob.exc.HTTPBadRequest: Invalid input received: limit must be an
  integer

  After:

  nova.exception.ValidationError: Invalid input for query parameters
  0. Value: abc. u'abc' does not match '^[0-9]*$'

  The exception raised also changed, which may be problematic for API
  consumers.

  We probably need another layer to transform these generated messages
  into something more user friendly, and perhaps consider raising
  HTTPBadRequest again with the nicer error message.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1655710/+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 1655704] [NEW] unable to configure horizon default volume device name

[Bradley Kite]

Public bug reported:

When an image has the attribute set to use "hw_scsi_model=virtio-scsi",
then the default device name should be "sda".

If the default device name remains 'vda', then it is not possible to add
a second disk.

This is because the LUN ID assigned to the second disk will conflict
with the first if the device names are different.

** Affects: horizon
 Importance: Undecided
 Status: New

** Patch added: "LAUNCH_INSTANCE_DEFAULTS.patch"
   
https://bugs.launchpad.net/bugs/1655704/+attachment/4802920/+files/LAUNCH_INSTANCE_DEFAULTS.patch

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

Title:
  unable to configure horizon default volume device name

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  When an image has the attribute set to use "hw_scsi_model=virtio-
  scsi", then the default device name should be "sda".

  If the default device name remains 'vda', then it is not possible to
  add a second disk.

  This is because the LUN ID assigned to the second disk will conflict
  with the first if the device names are different.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1655704/+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 1655471] Re: Update MTU on existing devices

[Boden R]

Marking neutron bug as invalid as per [1]. The openstack-manuals as
added as an affected project. Manuals need updating as per DoctImpact
comment.


[1] 
http://docs.openstack.org/developer/neutron/policies/bugs.html#bug-triage-process

** Also affects: openstack-manuals
   Importance: Undecided
   Status: New

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

Title:
  Update MTU on existing devices

Status in neutron:
  Invalid
Status in openstack-manuals:
  New

Bug description:
  https://review.openstack.org/412462
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/neutron" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

  commit 52f31b0ddbb978402f65850bf41ceb409c560d4f
  Author: Ihar Hrachyshka 
  Date:   Tue Nov 29 22:24:29 2016 +

  Update MTU on existing devices
  
  This patch makes OVS and Linuxbridge interface drivers to set MTU on
  plug() attempt if the device already exists. This helps when network MTU
  changes (which happens after some configuration file changes).
  
  This will allow to update MTU values on agent restart, without the need
  to bind all ports to new nodes, that would involve migrating agents. It
  will also help in case when you have no other nodes to migrate to (in
  single node mode).
  
  Both OVS and Linuxbridge interface drivers are updated.
  
  Other drivers (in-tree IVS as well as 3party drivers) will use the
  default set_mtu implementation, that only warns about the missing
  feature (once per process startup).
  
  DocImpact suggest to restart agents after MTU config changes instead of
rewiring router/DHCP ports.
  
  Related: If438e4816b425e6c5021a55567dcaaa77d1f
  Related: If09eda334cddc74910dda7a4fb498b7987714be3
  Closes-Bug: #1649845
  Change-Id: I3c6d6cb55c5808facec38f87114c2ddf548f05f1
  (cherry picked from commit 5c8dffa7fb6c95a04a7b50c7d6e63c9a2729231b)

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1655471/+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 1655670] Re: HTTP 404 when requesting /v3/domains/Default

[Boris Bobrov]

I think that this is expected. When --domain Default is passed,
openstackclient doesn't know what "Default" is -- id or name. So it
tries to fetch domain with id Default, and when fails, then tries to
fetch domain by name. This is definitely not keystone bug, and i think
that it is not a bug in python-openstackclient, though i will add it to
the bugreport.

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

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

Title:
  HTTP 404 when requesting /v3/domains/Default

Status in OpenStack Identity (keystone):
  Invalid
Status in python-openstackclient:
  New

Bug description:
  After running a Keystone test with Rally, I found a lot of HTTP 404
  errors in the Apache2 access log when requesting /v3/domains/Default.

  10.26.11.110 - - [16/Dec/2016:14:17:41 +0100] "GET /v3/domains/Default 
HTTP/1.1" 404 91 "-" "python-keystoneclient" 
  10.26.11.110 - - [16/Dec/2016:14:17:44 +0100] "GET /v3/domains/Default 
HTTP/1.1" 404 91 "-" "python-keystoneclient" 
  10.26.11.110 - - [16/Dec/2016:14:17:47 +0100] "GET /v3/domains/Default 
HTTP/1.1" 404 91 "-" "python-keystoneclient"

  I was able to reproduce this by executing the command "openstack project list 
--domain Default".
  I also found the appropriate entry in the Keystone log:

  2017-01-10 16:49:39.012184 2017-01-10 16:49:39.011 6748 INFO 
keystone.common.wsgi [req-ce3d7d7e-8dce-4dd5-8131-64ec7b047cc7 
3e23a62541e04ab6b9726e65060bbb33 e64f8ce1d278474d9989c38162ff7bdd - default 
default] GET https://identity-dd2d.cloudandheat.com:5000/v3/domains/Default
  2017-01-10 16:49:39.018540 2017-01-10 16:49:39.017 6748 WARNING 
keystone.common.wsgi [req-ce3d7d7e-8dce-4dd5-8131-64ec7b047cc7 
3e23a62541e04ab6b9726e65060bbb33 e64f8ce1d278474d9989c38162ff7bdd - default 
default] Could not find domain: Default

  It works well when you use the domain id instead (openstack project list 
--domain default).
  Please find the debug output attached.

  There are two GET requests for /v3/domains/Default. Both of them get the 404.
  The next request uses another URL (/v3/domains?name=Default) which works well.
  I assume that's why you get the list even when the 404s occur.

  We use OpenStack Newton with Keystone version 10.0.0.

  Steps to reproduce:
  1. Install DevStack
  2. Execute "openstack --debug project list --domain Default"

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1655670/+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 1524020] Re: DVRImpact: dvr_vmarp_table_update and dvr_update_router_add_vm is called for every port update instead of only when host binding or mac-address changes occur

[Swaminathan Vasudevan]

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

Title:
  DVRImpact:  dvr_vmarp_table_update and dvr_update_router_add_vm is
  called for every port update instead of only when host binding or mac-
  address changes occur

Status in neutron:
  Fix Released
Status in neutron kilo series:
  Fix Released

Bug description:
  DVR arp update (dvr_vmarp_table_update) and dvr_update_router_add_vm
  called for every update_port if the mac_address changes or when
  update_devic_up is true.

  These functions should be called from _notify_l3_agent_port_update,
  only when a host binding for a service port changes or when a
  mac_address for the service port changes.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1524020/+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 1554876] Re: router not found warning logs in the L3 agent

[Swaminathan Vasudevan]

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

Title:
  router not found warning logs in the L3 agent

Status in neutron:
  Fix Released

Bug description:
  The L3 agent during a normal tempest run will be filled with warnings
  like the following:

  2016-03-08 10:10:30.465 18962 WARNING neutron.agent.l3.agent [-] Info for 
router 3688a110-8cfe-41c6-84e3-bfd965238304 was not found. Performing router 
cleanup
  2016-03-08 10:10:34.197 18962 WARNING neutron.agent.l3.agent [-] Info for 
router 3688a110-8cfe-41c6-84e3-bfd965238304 was not found. Performing router 
cleanup
  2016-03-08 10:10:35.535 18962 WARNING neutron.agent.l3.agent [-] Info for 
router 3688a110-8cfe-41c6-84e3-bfd965238304 was not found. Performing router 
cleanup
  2016-03-08 10:10:43.025 18962 WARNING neutron.agent.l3.agent [-] Info for 
router 3688a110-8cfe-41c6-84e3-bfd965238304 was not found. Performing router 
cleanup
  2016-03-08 10:10:47.029 18962 WARNING neutron.agent.l3.agent [-] Info for 
router 3688a110-8cfe-41c6-84e3-bfd965238304 was not found. Performing router 
cleanup

  
  This is completely normal as routers are deleted from the server during the 
data retrieval process of the L3 agent and should not be at the warning level.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1554876/+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 1655196] Re: Remove advertise_mtu config option

[John Davidge]

There don't appear to be any remaining references to advertise_mtu in
the neutron tree. Looks like this affects openstack-manuals only.

** No longer affects: neutron

** Changed in: openstack-manuals
 Assignee: (unassigned) => John Davidge (john-davidge)

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

Title:
  Remove advertise_mtu config option

Status in openstack-manuals:
  Confirmed

Bug description:
  https://review.openstack.org/413567
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/neutron" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

  commit b09a380f9579efc0779fb38db2cdb47b7b9e29d1
  Author: Ihar Hrachyshka 
  Date:   Fri Dec 16 22:40:50 2016 +

  Remove advertise_mtu config option
  
  It was deprecated in Newton timeframe. Now we just clean it up from the
  tree.
  
  DocImpact: Any advertise_mtu option notions in documentation should be
  removed.
  
  UpgradeImpact: After upgrade, all DHCPv4 subnets will see the MTU option
  served via corresponding DHCPv4 option. Also, all IPv6 subnets connected
  to routers will see MTU set in Router Advertisement messages.
  
  NeutronLibImpact: This patch will break any 3party plugins that directly
  access the configuration option.
  
  Change-Id: I31e15018fe764de0fe4d6de7da3c1d9f2cc1d532

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-manuals/+bug/1655196/+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 1655670] [NEW] HTTP 404 when requesting /v3/domains/Default

[Daniel Trautmann]

Public bug reported:

After running a Keystone test with Rally, I found a lot of HTTP 404
errors in the Apache2 access log when requesting /v3/domains/Default.

10.26.11.110 - - [16/Dec/2016:14:17:41 +0100] "GET /v3/domains/Default 
HTTP/1.1" 404 91 "-" "python-keystoneclient" 
10.26.11.110 - - [16/Dec/2016:14:17:44 +0100] "GET /v3/domains/Default 
HTTP/1.1" 404 91 "-" "python-keystoneclient" 
10.26.11.110 - - [16/Dec/2016:14:17:47 +0100] "GET /v3/domains/Default 
HTTP/1.1" 404 91 "-" "python-keystoneclient"

I was able to reproduce this by executing the command "openstack project list 
--domain Default".
I also found the appropriate entry in the Keystone log:

2017-01-10 16:49:39.012184 2017-01-10 16:49:39.011 6748 INFO 
keystone.common.wsgi [req-ce3d7d7e-8dce-4dd5-8131-64ec7b047cc7 
3e23a62541e04ab6b9726e65060bbb33 e64f8ce1d278474d9989c38162ff7bdd - default 
default] GET https://identity-dd2d.cloudandheat.com:5000/v3/domains/Default
2017-01-10 16:49:39.018540 2017-01-10 16:49:39.017 6748 WARNING 
keystone.common.wsgi [req-ce3d7d7e-8dce-4dd5-8131-64ec7b047cc7 
3e23a62541e04ab6b9726e65060bbb33 e64f8ce1d278474d9989c38162ff7bdd - default 
default] Could not find domain: Default

It works well when you use the domain id instead (openstack project list 
--domain default).
Please find the debug output attached.

There are two GET requests for /v3/domains/Default. Both of them get the 404.
The next request uses another URL (/v3/domains?name=Default) which works well.
I assume that's why you get the list even when the 404s occur.

We use OpenStack Newton with Keystone version 10.0.0.

Steps to reproduce:
1. Install DevStack
2. Execute "openstack --debug project list --domain Default"

** Affects: keystone
 Importance: Undecided
 Status: New

** Attachment added: "OpenStack command debug output"
   
https://bugs.launchpad.net/bugs/1655670/+attachment/4802881/+files/404_project_list.txt

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

Title:
  HTTP 404 when requesting /v3/domains/Default

Status in OpenStack Identity (keystone):
  New

Bug description:
  After running a Keystone test with Rally, I found a lot of HTTP 404
  errors in the Apache2 access log when requesting /v3/domains/Default.

  10.26.11.110 - - [16/Dec/2016:14:17:41 +0100] "GET /v3/domains/Default 
HTTP/1.1" 404 91 "-" "python-keystoneclient" 
  10.26.11.110 - - [16/Dec/2016:14:17:44 +0100] "GET /v3/domains/Default 
HTTP/1.1" 404 91 "-" "python-keystoneclient" 
  10.26.11.110 - - [16/Dec/2016:14:17:47 +0100] "GET /v3/domains/Default 
HTTP/1.1" 404 91 "-" "python-keystoneclient"

  I was able to reproduce this by executing the command "openstack project list 
--domain Default".
  I also found the appropriate entry in the Keystone log:

  2017-01-10 16:49:39.012184 2017-01-10 16:49:39.011 6748 INFO 
keystone.common.wsgi [req-ce3d7d7e-8dce-4dd5-8131-64ec7b047cc7 
3e23a62541e04ab6b9726e65060bbb33 e64f8ce1d278474d9989c38162ff7bdd - default 
default] GET https://identity-dd2d.cloudandheat.com:5000/v3/domains/Default
  2017-01-10 16:49:39.018540 2017-01-10 16:49:39.017 6748 WARNING 
keystone.common.wsgi [req-ce3d7d7e-8dce-4dd5-8131-64ec7b047cc7 
3e23a62541e04ab6b9726e65060bbb33 e64f8ce1d278474d9989c38162ff7bdd - default 
default] Could not find domain: Default

  It works well when you use the domain id instead (openstack project list 
--domain default).
  Please find the debug output attached.

  There are two GET requests for /v3/domains/Default. Both of them get the 404.
  The next request uses another URL (/v3/domains?name=Default) which works well.
  I assume that's why you get the list even when the 404s occur.

  We use OpenStack Newton with Keystone version 10.0.0.

  Steps to reproduce:
  1. Install DevStack
  2. Execute "openstack --debug project list --domain Default"

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1655670/+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 1655662] [NEW] libvirt xen hvm guests can't hot plug (attach detach) default block devices

[Nikita Gerasimov]

Public bug reported:

Currently default disk bus for libvirt+Xen HVM guests is "ide", which
not allow hot reconfiguration. So images without special metadata
property specifying bus can't be attached or detached.

https://github.com/openstack/nova/blob/ad1c7ac2b102112280a25927d731edb168f80998/nova/virt/libvirt/blockinfo.py#L250

At the same time QEMU/KVM guests have "virtio" as default disk bus for
disk which is QEMU analog of "xen" bus for XEN.

Fix looks trivial and require only delete XEN HVM specific part to
return "xen" as default part in all cases. User will be able to use
other buses by metadata and only when it's really required.

** Affects: nova
 Importance: Undecided
 Status: New


** Tags: libvirt xen

** Tags added: libvirt xen

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

Title:
  libvirt xen hvm guests can't  hot plug (attach detach) default block
  devices

Status in OpenStack Compute (nova):
  New

Bug description:
  Currently default disk bus for libvirt+Xen HVM guests is "ide", which
  not allow hot reconfiguration. So images without special metadata
  property specifying bus can't be attached or detached.

  
https://github.com/openstack/nova/blob/ad1c7ac2b102112280a25927d731edb168f80998/nova/virt/libvirt/blockinfo.py#L250

  At the same time QEMU/KVM guests have "virtio" as default disk bus for
  disk which is QEMU analog of "xen" bus for XEN.

  Fix looks trivial and require only delete XEN HVM specific part to
  return "xen" as default part in all cases. User will be able to use
  other buses by metadata and only when it's really required.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1655662/+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 1593571] Re: [Mitaka] 'AttributeError: name' when using multiple domain with LDAP driver

[Johsua Griffiths]

** Also affects: openstack-dashboard (Ubuntu)
   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/1593571

Title:
  [Mitaka] 'AttributeError: name' when using multiple domain with LDAP
  driver

Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in openstack-dashboard package in Ubuntu:
  New

Bug description:
  I get 'AttributeError: name' when using multiple domain with LDAP driver.
  Specifically, when I click 'Create Project', 'Manage Members', 'Modify 
Groups', 'Edit Project' and 'Modify Quotas' button on the 'Projects' page of 
'Identify' menu, horizon makes those error messages below.

  It doesn't seem to be related to keystone since there is no error
  message from keystone node and I can do those operations using CLI
  without any problem.

  ==> /var/log/apache2/error.log <==


[97/7522]
  [Fri Jun 17 14:44:57.440997 2016] [wsgi:error] [pid 93971:tid 
140574614624000] Problem instantiating action class.
  [Fri Jun 17 14:44:57.441049 2016] [wsgi:error] [pid 93971:tid 
140574614624000] Traceback (most recent call last):
  [Fri Jun 17 14:44:57.441060 2016] [wsgi:error] [pid 93971:tid 
140574614624000]   File 
"/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../horizon/workflows/base.py",
 line 370, in action
  [Fri Jun 17 14:44:57.441083 2016] [wsgi:error] [pid 93971:tid 
140574614624000] context)
  [Fri Jun 17 14:44:57.441123 2016] [wsgi:error] [pid 93971:tid 
140574614624000]   File 
"/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/dashboards/identity/projects/workflows.py",
 line 323, in __init__
  [Fri Jun 17 14:44:57.441141 2016] [wsgi:error] [pid 93971:tid 
140574614624000] groups_list = [(group.id, group.name) for group in 
all_groups]
  [Fri Jun 17 14:44:57.441157 2016] [wsgi:error] [pid 93971:tid 
140574614624000]   File 
"/usr/lib/python2.7/dist-packages/keystoneclient/base.py", line 491, in 
__getattr__
  [Fri Jun 17 14:44:57.441182 2016] [wsgi:error] [pid 93971:tid 
140574614624000] raise AttributeError(k)
  [Fri Jun 17 14:44:57.441199 2016] [wsgi:error] [pid 93971:tid 
140574614624000] AttributeError: name
  [Fri Jun 17 14:44:57.442367 2016] [wsgi:error] [pid 93971:tid 
140574614624000] Internal Server Error: 
/horizon/identity/04e7fe0cfb19418a9ec2eacfe1d334d5/update/
  [Fri Jun 17 14:44:57.442389 2016] [wsgi:error] [pid 93971:tid 
140574614624000] Traceback (most recent call last):
  [Fri Jun 17 14:44:57.442420 2016] [wsgi:error] [pid 93971:tid 
140574614624000]   File 
"/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line 164, in 
get_response
  [Fri Jun 17 14:44:57.442439 2016] [wsgi:error] [pid 93971:tid 
140574614624000] response = response.render()
  [Fri Jun 17 14:44:57.442455 2016] [wsgi:error] [pid 93971:tid 
140574614624000]   File 
"/usr/lib/python2.7/dist-packages/django/template/response.py", line 158, in 
render
  [Fri Jun 17 14:44:57.442480 2016] [wsgi:error] [pid 93971:tid 
140574614624000] self.content = self.rendered_content
  [Fri Jun 17 14:44:57.442497 2016] [wsgi:error] [pid 93971:tid 
140574614624000]   File 
"/usr/lib/python2.7/dist-packages/django/template/response.py", line 135, in 
rendered_content
  [Fri Jun 17 14:44:57.442514 2016] [wsgi:error] [pid 93971:tid 
140574614624000] content = template.render(context, self._request)
  [Fri Jun 17 14:44:57.442530 2016] [wsgi:error] [pid 93971:tid 
140574614624000]   File 
"/usr/lib/python2.7/dist-packages/django/template/backends/django.py", line 74, 
in render
  [Fri Jun 17 14:44:57.442555 2016] [wsgi:error] [pid 93971:tid 
140574614624000] return self.template.render(context)
  [Fri Jun 17 14:44:57.442579 2016] [wsgi:error] [pid 93971:tid 
140574614624000]   File 
"/usr/lib/python2.7/dist-packages/django/template/base.py", line 210, in render
  [Fri Jun 17 14:44:57.442596 2016] [wsgi:error] [pid 93971:tid 
140574614624000] return self._render(context)
  [Fri Jun 17 14:44:57.443601 2016] [wsgi:error] [pid 93971:tid 
140574614624000]   File 
"/usr/lib/python2.7/dist-packages/django/template/base.py", line 202, in _render
  [Fri Jun 17 14:44:57.443632 2016] [wsgi:error] [pid 93971:tid 
140574614624000] return self.nodelist.render(context)
  [Fri Jun 17 14:44:57.443649 2016] [wsgi:error] [pid 93971:tid 
140574614624000]   File 
"/usr/lib/python2.7/dist-packages/django/template/base.py", line 905, in render
  [Fri Jun 17 14:44:57.443666 2016] [wsgi:error] [pid 93971:tid 
140574614624000] bit = self.render_node(node, context)
  [Fri Jun 17 14:44:57.443696 2016] [wsgi:error] [pid 93971:tid 

[Yahoo-eng-team] [Bug 1655610] [NEW] alembic_version table has no primary key

[Proskurin Kirill]

Public bug reported:

Currently alembic_version table in the neutron db has no primary key.

Which is a bad thing, if you consider to use Galera as a database, since
it requires primary keys in all tables.

For example, during the "INFO  [alembic.runtime.migration] Running
upgrade  -> kilo, kilo_initial" migration you will get the:

oslo_db.exception.DBError: (pymysql.err.InternalError) (1105, u'Percona-
XtraDB-Cluster prohibits use of DML command on a table
(neutron.alembic_version) without an explicit primary key with
pxc_strict_mode = ENFORCING or MASTER') [SQL: u"INSERT INTO
alembic_version (version_num) VALUES ('kilo')"]

** Affects: neutron
 Importance: Undecided
 Assignee: Ann Taraday (akamyshnikova)
 Status: New


** Tags: db

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

Title:
  alembic_version table has no primary key

Status in neutron:
  New

Bug description:
  Currently alembic_version table in the neutron db has no primary key.

  Which is a bad thing, if you consider to use Galera as a database,
  since it requires primary keys in all tables.

  For example, during the "INFO  [alembic.runtime.migration] Running
  upgrade  -> kilo, kilo_initial" migration you will get the:

  oslo_db.exception.DBError: (pymysql.err.InternalError) (1105, u
  'Percona-XtraDB-Cluster prohibits use of DML command on a table
  (neutron.alembic_version) without an explicit primary key with
  pxc_strict_mode = ENFORCING or MASTER') [SQL: u"INSERT INTO
  alembic_version (version_num) VALUES ('kilo')"]

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1655610/+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 1655605] [NEW] metadata proxy won't start in dhcp namespace when network(subnet) is removed from router

[Perry]

Public bug reported:

When adding network(subnet) into router immediately after creating
network(subnet), there is no metadata proxy process created in dhcp
namespace to listen on port 80. It causes problem when deleted
network(subnet) from router: it won't call metadata service successfully
until restarting dhcp service. Restarting dhcp service is just a
workaround and is not acceptable as solution.


This problem is introduced in Newton release. When adding network, it
will check whether the network has isolated ipv4 subnet. It queries all
ports belonging to the network, and see whether there is any port used
as gateway. if yes, then it thinks the subnet is not isolated. If we add
subnet to router immediately after creating subnet, the process of
network creation( creating metadata proxy) and the process of adding
subnet to interface happens at the same time. The seconds process
creates port as gateway quickly and then the first process checks and
treats it no isolated, and then will kill metadata proxy created soon
earlier.

# /etc/neutron/dhcp_agent.ini
enable_isolated_metadata = True
enable_metadata_network = True

#execute the following commands in batch without interruption.
neutron net-create network_1
neutron subnet-create --name subnet_1 network_1 172.60.0.0/24
neutron router-interface-add default subnet_1

# there is no 80 port.
 ip netns exec qdhcp-c5791b7d-ec3e-4e96-9a32-b9d1217ed330 netstat -tunlp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       
PID/Program name   
tcp        0      0 172.16.255.2:53         0.0.0.0:*               LISTEN      
16926/dnsmasq      
tcp        0      0 169.254.169.254:53      0.0.0.0:*               LISTEN      
16926/dnsmasq      
tcp6       0      0 fe80::f816:3eff:fe80:53 :::*                    LISTEN      
16926/dnsmasq      
udp        0      0 172.16.255.2:53         0.0.0.0:*                           
16926/dnsmasq      
udp        0      0 169.254.169.254:53      0.0.0.0:*                           
16926/dnsmasq      
udp        0      0 0.0.0.0:67              0.0.0.0:*                           
16926/dnsmasq      
udp6       0      0 :::547                  :::*                                
16926/dnsmasq      
udp6       0      0 fe80::f816:3eff:fe80:53 :::*                                
16926/dnsmasq

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

Title:
  metadata proxy won't start in dhcp namespace when network(subnet) is
  removed from router

Status in neutron:
  New

Bug description:
  When adding network(subnet) into router immediately after creating
  network(subnet), there is no metadata proxy process created in dhcp
  namespace to listen on port 80. It causes problem when deleted
  network(subnet) from router: it won't call metadata service
  successfully until restarting dhcp service. Restarting dhcp service is
  just a workaround and is not acceptable as solution.


  This problem is introduced in Newton release. When adding network, it
  will check whether the network has isolated ipv4 subnet. It queries
  all ports belonging to the network, and see whether there is any port
  used as gateway. if yes, then it thinks the subnet is not isolated. If
  we add subnet to router immediately after creating subnet, the process
  of network creation( creating metadata proxy) and the process of
  adding subnet to interface happens at the same time. The seconds
  process creates port as gateway quickly and then the first process
  checks and treats it no isolated, and then will kill metadata proxy
  created soon earlier.

  # /etc/neutron/dhcp_agent.ini
  enable_isolated_metadata = True
  enable_metadata_network = True

  #execute the following commands in batch without interruption.
  neutron net-create network_1
  neutron subnet-create --name subnet_1 network_1 172.60.0.0/24
  neutron router-interface-add default subnet_1

  # there is no 80 port.
   ip netns exec qdhcp-c5791b7d-ec3e-4e96-9a32-b9d1217ed330 netstat -tunlp
  Active Internet connections (only servers)
  Proto Recv-Q Send-Q Local Address           Foreign Address         State     
  PID/Program name   
  tcp        0      0 172.16.255.2:53         0.0.0.0:*               LISTEN    
  16926/dnsmasq      
  tcp        0      0 169.254.169.254:53      0.0.0.0:*               LISTEN    
  16926/dnsmasq      
  tcp6       0      0 fe80::f816:3eff:fe80:53 :::*                    LISTEN    
  16926/dnsmasq      
  udp        0      0 172.16.255.2:53         0.0.0.0:*                         
  16926/dnsmasq      
  udp        0      0 169.254.169.254:53      0.0.0.0:*                         
  16926/dnsmasq      
  udp        0      0 0.0.0.0:67              0.0.0.0:*                         
  16926/dnsmasq      
  udp6    

[Yahoo-eng-team] [Bug 1655393] Re: manila-ui quotas override part of the default quotas

[Itxaka Serrano]

** Project changed: manila-ui => horizon

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

Title:
  manila-ui quotas override part of the default quotas

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  Versions affected: mitaka and higher.
  Under Admin -> Defaults -> Update defaults

  
  Due to manila-ui overriding the default quotas from horizon, it makes the 
"Update Default Quotas" workflow miss some initial values ('Key Pairs' and 
'Length of Injected File Path')

  This is due to this line of code: https://github.com/openstack/manila-
  ui/blob/stable/mitaka/manila_ui/dashboards/project/shares/__init__.py#L81

  quotas.QUOTA_FIELDS = quotas.QUOTA_FIELDS + MANILA_QUOTA_FIELDS

  This assumes that all the quotas available are in quotas.QUOTA_FIELDS but 
unfortunately, for some historical reason Im sure, there is some extra quotas 
not available on that tuple:
  
https://github.com/openstack/horizon/blob/master/openstack_dashboard/usage/quotas.py#L44

  MISSING_QUOTA_FIELDS = ("key_pairs",
  "injected_file_path_bytes",)

  
  This causes the quotas to appear correctly when viewing them on Admin -> 
Defaults, but when editing their values get lost.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1655393/+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 1655393] [NEW] manila-ui quotas override part of the default quotas

[Launchpad Bug Tracker]

You have been subscribed to a public bug:

Versions affected: mitaka and higher.
Under Admin -> Defaults -> Update defaults


Due to manila-ui overriding the default quotas from horizon, it makes the 
"Update Default Quotas" workflow miss some initial values ('Key Pairs' and 
'Length of Injected File Path')

This is due to this line of code: https://github.com/openstack/manila-
ui/blob/stable/mitaka/manila_ui/dashboards/project/shares/__init__.py#L81

quotas.QUOTA_FIELDS = quotas.QUOTA_FIELDS + MANILA_QUOTA_FIELDS

This assumes that all the quotas available are in quotas.QUOTA_FIELDS but 
unfortunately, for some historical reason Im sure, there is some extra quotas 
not available on that tuple:
https://github.com/openstack/horizon/blob/master/openstack_dashboard/usage/quotas.py#L44

MISSING_QUOTA_FIELDS = ("key_pairs",
"injected_file_path_bytes",)


This causes the quotas to appear correctly when viewing them on Admin -> 
Defaults, but when editing their values get lost.

** Affects: horizon
 Importance: Undecided
 Assignee: Itxaka Serrano (itxakaserrano)
 Status: In Progress


** Tags: newton-backport-potential
-- 
manila-ui quotas override part of the default quotas
https://bugs.launchpad.net/bugs/1655393
You received this bug notification because you are a member of Yahoo! 
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).

-- 
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 1654990] Re: Vm creation getting failed with image not found error

[Lee Yarwood]

This doesn't appear to be a nova issue, the keystone error in c#2
suggesting an issue with memcached in your environment that in turn is
bubbling back up to Glance and finally Nova.

Liberty is also an unsupported release at present so I'm marking this as
invalid for now but feel free to change this if you are able to
reproduce this against a supported release.

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

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

Title:
  Vm creation getting failed with image not found error

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  We have Liberty setup with all services in HA. Sometimes vm creation
  is getting failed throwing below error. We are getting this error
  randomly.

  " nCould not find image fdc-centos7-image: 500 Internal Server Error
  Unexpected API Error. Please report this at
  http://bugs.launchpad.net/nova/ and attach the Nova API log if
  possible.\n\n\n "

  Below is the nova api log:

  2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions 
[req-6f2cacb2-c36b-464e-b816-3caad8c24746 3612616185a748f788fb0532729ccc3a 
5896939c506840c2bf083cb1100bee2b - - -] Unexpected exception in API method
  2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions Traceback 
(most recent call last):
  2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/api/openstack/extensions.py", line 478, 
in wrapped
  2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions return 
f(*args, **kwargs)
  2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/api/openstack/compute/images.py", line 
145, in detail
  2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions 
**page_params)
  2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/image/api.py", line 68, in get_all
  2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions return 
session.detail(context, **kwargs)
  2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/image/glance.py", line 284, in detail
  2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions for image 
in images:
  2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/glanceclient/v1/images.py", line 254, in list
  2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions for image 
in paginate(params, return_request_id):
  2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/glanceclient/v1/images.py", line 238, in 
paginate
  2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions images, 
resp = self._list(url, "images")
  2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/glanceclient/v1/images.py", line 63, in _list
  2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions resp, 
body = self.client.get(url)
  2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/glanceclient/common/http.py", line 280, in get
  2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions return 
self._request('GET', url, **kwargs)
  2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/glanceclient/common/http.py", line 272, in 
_request
  2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions resp, 
body_iter = self._handle_response(resp)
  2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/glanceclient/common/http.py", line 93, in 
_handle_response
  2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions raise 
exc.from_response(resp, resp.content)
  2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions 
HTTPInternalServerError: 500 Internal Server Error: The server has either erred 
or is incapable of performing the requested operation. (HTTP 500)
  2017-01-09 05:19:00.582 592 ERROR nova.api.openstack.extensions
  2017-01-09 05:19:00.583 592 INFO nova.api.openstack.wsgi 
[req-6f2cacb2-c36b-464e-b816-3caad8c24746 3612616185a748f788fb0532729ccc3a 
5896939c506840c2bf083cb1100bee2b - - -] HTTP exception thrown: Unexpected API 
Error. Please report this at http://bugs.launchpad.net/nova/ and attach the 
Nova API log if possible.
  

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

[Yahoo-eng-team] [Bug 1655579] [NEW] Attached port with disabled security does not work properly

[Bartłomiej Daca]

Public bug reported:

When I attach port with disabled security to a vm, I am not able to use
this port.

Steps to reproduce:

1. Create port and disable security:

neutron port-create --name test-sec-group --no-security-groups 
neutron port-update  --port-security-enabled=False

2. Attach port to vm

nova interface-attach  --port-id 

After this steps I am unable to use this port on the vm (for example
obtain dhcp lease). The cause that I identified is that after this steps
the iptables on the host with vm is not configured properly. I can't see
rules that should be there:

-A neutron-openvswi-FORWARD -m physdev --physdev-out  
--physdev-is-bridged -m comment --comment "Accept all packets when port 
security is disabled." -j ACCEPT
-A neutron-openvswi-FORWARD -m physdev --physdev-in  
--physdev-is-bridged -m comment --comment "Accept all packets when port 
security is disabled." -j ACCEPT
-A neutron-openvswi-INPUT -m physdev --physdev-in  
--physdev-is-bridged -m comment --comment "Accept all packets when port 
security is disabled." -j ACCEPT

When I add this rules manually, everything works fine.

Another scenario when everything works fine: change steps order - create
port, attach it and then disable security.

My environment: 
* Openstack mitaka on centos 7
* neutron version: neutron-8.2.0
* nova version: nova-13.1.1

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

Title:
  Attached port with disabled security does not work properly

Status in neutron:
  New

Bug description:
  When I attach port with disabled security to a vm, I am not able to
  use this port.

  Steps to reproduce:

  1. Create port and disable security:

  neutron port-create --name test-sec-group --no-security-groups 
  neutron port-update  --port-security-enabled=False

  2. Attach port to vm

  nova interface-attach  --port-id 

  After this steps I am unable to use this port on the vm (for example
  obtain dhcp lease). The cause that I identified is that after this
  steps the iptables on the host with vm is not configured properly. I
  can't see rules that should be there:

  -A neutron-openvswi-FORWARD -m physdev --physdev-out  
--physdev-is-bridged -m comment --comment "Accept all packets when port 
security is disabled." -j ACCEPT
  -A neutron-openvswi-FORWARD -m physdev --physdev-in  
--physdev-is-bridged -m comment --comment "Accept all packets when port 
security is disabled." -j ACCEPT
  -A neutron-openvswi-INPUT -m physdev --physdev-in  
--physdev-is-bridged -m comment --comment "Accept all packets when port 
security is disabled." -j ACCEPT

  When I add this rules manually, everything works fine.

  Another scenario when everything works fine: change steps order -
  create port, attach it and then disable security.

  My environment: 
  * Openstack mitaka on centos 7
  * neutron version: neutron-8.2.0
  * nova version: nova-13.1.1

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1655579/+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 1655567] [NEW] DHCPv6 failures with "address already allocated in subnet" error

[IWAMOTO Toshihiro]

Public bug reported:

Test failures with the DHCPv6 error from multiple test methods.

Use query:
http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22already%20allocated%20in%20subnet%5C%22

An example:

 ==
2017-01-11 05:00:04.479808 | Failed 1 tests - output below:
2017-01-11 05:00:04.479858 | ==
2017-01-11 05:00:04.479883 | 
2017-01-11 05:00:04.479962 | 
tempest.api.network.test_dhcp_ipv6.NetworksTestDHCPv6.test_dhcpv6_stateless_eui64[id-e5517e62-6f16-430d-a672-f80875493d4c]
2017-01-11 05:00:04.480056 | 
--
2017-01-11 05:00:04.480082 | 
2017-01-11 05:00:04.480113 | Captured traceback:
2017-01-11 05:00:04.480154 | ~~~
2017-01-11 05:00:04.480204 | Traceback (most recent call last):
2017-01-11 05:00:04.480283 |   File 
"tempest/api/network/test_dhcp_ipv6.py", line 109, in 
test_dhcpv6_stateless_eui64
2017-01-11 05:00:04.480415 | real_ip, eui_ip = 
self._get_ips_from_subnet(**kwargs)
2017-01-11 05:00:04.480486 |   File 
"tempest/api/network/test_dhcp_ipv6.py", line 90, in _get_ips_from_subnet
2017-01-11 05:00:04.480551 | subnet = self.create_subnet(self.network, 
**kwargs)
2017-01-11 05:00:04.480607 |   File "tempest/api/network/base.py", line 
179, in create_subnet
2017-01-11 05:00:04.481118 | **kwargs)
2017-01-11 05:00:04.481198 |   File 
"tempest/lib/services/network/subnets_client.py", line 27, in create_subnet
2017-01-11 05:00:04.481260 | return self.create_resource(uri, post_data)
2017-01-11 05:00:04.481756 |   File "tempest/lib/services/network/base.py", 
line 60, in create_resource
2017-01-11 05:00:04.481830 | resp, body = self.post(req_uri, 
req_post_data)
2017-01-11 05:00:04.481887 |   File "tempest/lib/common/rest_client.py", 
line 276, in post
2017-01-11 05:00:04.481946 | return self.request('POST', url, 
extra_headers, headers, body, chunked)
2017-01-11 05:00:04.482000 |   File "tempest/lib/common/rest_client.py", 
line 664, in request
2017-01-11 05:00:04.482042 | self._error_checker(resp, resp_body)
2017-01-11 05:00:04.482098 |   File "tempest/lib/common/rest_client.py", 
line 776, in _error_checker
2017-01-11 05:00:04.482145 | raise exceptions.Conflict(resp_body, 
resp=resp)
2017-01-11 05:00:04.482204 | tempest.lib.exceptions.Conflict: An object 
with that identifier already exists
2017-01-11 05:00:04.482325 | Details: {u'detail': u'', u'message': u'IP 
address 2003::f816:3eff:fe18:34ee already allocated in subnet 
181627ba-b8ff-49c2-b97d-21763a0b572c', u'type': u'IpAddressAlreadyAllocated'}

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: gate-failure ipv6

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

Title:
  DHCPv6 failures with "address already allocated in subnet" error

Status in neutron:
  New

Bug description:
  Test failures with the DHCPv6 error from multiple test methods.

  Use query:
  
http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22already%20allocated%20in%20subnet%5C%22

  An example:

   ==
  2017-01-11 05:00:04.479808 | Failed 1 tests - output below:
  2017-01-11 05:00:04.479858 | ==
  2017-01-11 05:00:04.479883 | 
  2017-01-11 05:00:04.479962 | 
tempest.api.network.test_dhcp_ipv6.NetworksTestDHCPv6.test_dhcpv6_stateless_eui64[id-e5517e62-6f16-430d-a672-f80875493d4c]
  2017-01-11 05:00:04.480056 | 
--
  2017-01-11 05:00:04.480082 | 
  2017-01-11 05:00:04.480113 | Captured traceback:
  2017-01-11 05:00:04.480154 | ~~~
  2017-01-11 05:00:04.480204 | Traceback (most recent call last):
  2017-01-11 05:00:04.480283 |   File 
"tempest/api/network/test_dhcp_ipv6.py", line 109, in 
test_dhcpv6_stateless_eui64
  2017-01-11 05:00:04.480415 | real_ip, eui_ip = 
self._get_ips_from_subnet(**kwargs)
  2017-01-11 05:00:04.480486 |   File 
"tempest/api/network/test_dhcp_ipv6.py", line 90, in _get_ips_from_subnet
  2017-01-11 05:00:04.480551 | subnet = 
self.create_subnet(self.network, **kwargs)
  2017-01-11 05:00:04.480607 |   File "tempest/api/network/base.py", line 
179, in create_subnet
  2017-01-11 05:00:04.481118 | **kwargs)
  2017-01-11 05:00:04.481198 |   File 
"tempest/lib/services/network/subnets_client.py", line 27, in create_subnet
  2017-01-11 05:00:04.481260 | return self.create_resource(uri, 
post_data)
  2017-01-11 05:00:04.481756 |   File 
"tempest/lib/services/network/base.py", line 60, in create_resource
  2017-01-11 

[Yahoo-eng-team] [Bug 1655560] [NEW] Horizon doesn't obtain domain scoped tokens for users coming through websso

[Radu Pasea]

Public bug reported:

We have a Mitaka deployment in which users can login using an external
SSO service and the Keystone external authentication protocol and are
mapped to a Keytone domain. Domain admin users from that domain can't
perform any admin operations in the frontend because Horizon doesn't
obtain a domain scoped token.

With external authentication, Keystone tokens always have the user
domain present, so this shouldn't be an issue in Horizon.

In my opinion, the bug is in the django_openstack_auth project. Here, on
the websso path, I think the user domain is expected to be provided by
the user in the login page, which, of course, isn't possible for websso.

As a solution, the unscoped Keystone token can be checked for the user
domain.

I have attached a patch for the 2.2.1 tag of django_openstack_auth.
Seeing code here hasn't been modified in a long time, the bug should
manifest itself in the newest version of Horizon.

** Affects: horizon
 Importance: Undecided
 Status: New


** Tags: dashboard-core

** Patch added: "Patch django_openstack_auth tag 2.2.1"
   
https://bugs.launchpad.net/bugs/1655560/+attachment/4802757/+files/websso_domain.patch

** Description changed:

  We have a Mitaka deployment in which users can login using an external
  SSO service and the Keystone external authentication protocol and are
  mapped to a Keytone domain. Domain admin users from that domain can't
  perform any admin operations in the frontend because Horizon doesn't
  obtain a domain scoped token.
  
  With external authentication, Keystone tokens always have the user
  domain present, so this shouldn't be an issue in Horizon.
  
  In my opinion, the bug is in the django_openstack_auth project. Here, on
  the websso path, I think the user domain is expected to be provided by
  the user in the login page, which, of course, isn't possible for websso.
  
  As a solution, the unscoped Keystone token can be checked for the user
  domain.
  
  I have attached a patch for the 2.2.1 tag of django_openstack_auth.
  Seeing code here hasn't been modified in a long time, the bug should
- manifest in the newest version of Horizon.
+ manifest itself in the newest version of Horizon.

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

Title:
  Horizon doesn't obtain domain scoped tokens for users coming through
  websso

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  We have a Mitaka deployment in which users can login using an external
  SSO service and the Keystone external authentication protocol and are
  mapped to a Keytone domain. Domain admin users from that domain can't
  perform any admin operations in the frontend because Horizon doesn't
  obtain a domain scoped token.

  With external authentication, Keystone tokens always have the user
  domain present, so this shouldn't be an issue in Horizon.

  In my opinion, the bug is in the django_openstack_auth project. Here,
  on the websso path, I think the user domain is expected to be provided
  by the user in the login page, which, of course, isn't possible for
  websso.

  As a solution, the unscoped Keystone token can be checked for the user
  domain.

  I have attached a patch for the 2.2.1 tag of django_openstack_auth.
  Seeing code here hasn't been modified in a long time, the bug should
  manifest itself in the newest version of Horizon.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1655560/+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 1655558] [NEW] vmware create vm instance from snapshot error

[YuYang]

Public bug reported:

my environment is:
vcenter version 6.0, vsan version 6.0, and the neutron use vmware's NSX!
openstack is deploy by fuel 9.0,then the openstack version is mitaka!

when i create a snapshot from vm instance,and the deploy the new vm
instance from the snapshot ,get the error:

2016-12-22 07:11:59.884 4011 ERROR nova.virt.vmwareapi.images Traceback (most 
recent call last):
2016-12-22 07:11:59.884 4011 ERROR nova.virt.vmwareapi.images   File 
"/usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/images.py", line 186, in 
image_transfer
2016-12-22 07:11:59.884 4011 ERROR nova.virt.vmwareapi.images data = 
read_handle.read(CHUNK_SIZE)
2016-12-22 07:11:59.884 4011 ERROR nova.virt.vmwareapi.images   File 
"/usr/lib/python2.7/dist-packages/oslo_vmware/rw_handles.py", line 645, in read
2016-12-22 07:11:59.884 4011 ERROR nova.virt.vmwareapi.images data = 
next(self._iter)
2016-12-22 07:11:59.884 4011 ERROR nova.virt.vmwareapi.images   File 
"/usr/lib/python2.7/dist-packages/oslo_vmware/rw_handles.py", line 653, in 
get_next
2016-12-22 07:11:59.884 4011 ERROR nova.virt.vmwareapi.images for data in 
self._glance_read_iter:
2016-12-22 07:11:59.884 4011 ERROR nova.virt.vmwareapi.images   File 
"/usr/lib/python2.7/dist-packages/glanceclient/common/utils.py", line 477, in 
__iter__
2016-12-22 07:11:59.884 4011 ERROR nova.virt.vmwareapi.images for chunk in 
self.iterable:
2016-12-22 07:11:59.884 4011 ERROR nova.virt.vmwareapi.images   File 
"/usr/lib/python2.7/dist-packages/glanceclient/common/utils.py", line 435, in 
integrity_iter
2016-12-22 07:11:59.884 4011 ERROR nova.virt.vmwareapi.images (md5sum, 
checksum))
2016-12-22 07:11:59.884 4011 ERROR nova.virt.vmwareapi.images IOError: [Errno 
32] Corrupt image download. Checksum was 4aeaba2179866eb9d9b801d679964dfa 
expected f28c8836cf65c087e8b43f4c798477f6
2016-12-22 07:11:59.884 4011 ERROR nova.virt.vmwareapi.images 
<183>Dec 22 07:11:59 node-10 nova-compute: 2016-12-22 07:11:59.899 4011 DEBUG 
oslo_vmware.rw_handles [req-985a3617-9d0b-4ee7-926d-49e11578a811 
a0f3b1d5ef8842ac88e3ebd976685d88 9f7fc3501e654b0eb0166bf8be207044 - - -] 
Getting lease state for 
https://192.168.103.98/nfc/5201b6e8-5cc7-e7bf-dc30-1300dda05ae0/disk-0.vmdk. 
close /usr/lib/python2.7/dist-packages/oslo_vmware/rw_handles.py:455
<183>Dec 22 07:11:59 node-10 nova-compute: 2016-12-22 07:11:59.900 4011 DEBUG 
oslo_vmware.api [req-985a3617-9d0b-4ee7-926d-49e11578a811 
a0f3b1d5ef8842ac88e3ebd976685d88 9f7fc3501e654b0eb0166bf8be207044 - - -] 
Waiting for function oslo_vmware.api._invoke_api to return. func 
/usr/lib/python2.7/dist-packages/oslo_vmware/api.py:122
<183>Dec 22 07:11:59 node-10 nova-compute: 2016-12-22 07:11:59.914 4011 DEBUG 
oslo_vmware.rw_handles [req-985a3617-9d0b-4ee7-926d-49e11578a811 
a0f3b1d5ef8842ac88e3ebd976685d88 9f7fc3501e654b0eb0166bf8be207044 - - -] Lease 
for https://192.168.103.98/nfc/5201b6e8-5cc7-e7bf-dc30-1300dda05ae0/disk-0.vmdk 
is in state: ready. close 
/usr/lib/python2.7/dist-packages/oslo_vmware/rw_handles.py:464
<183>Dec 22 07:11:59 node-10 nova-compute: 2016-12-22 07:11:59.915 4011 DEBUG 
oslo_vmware.rw_handles [req-985a3617-9d0b-4ee7-926d-49e11578a811 
a0f3b1d5ef8842ac88e3ebd976685d88 9f7fc3501e654b0eb0166bf8be207044 - - -] 
Releasing lease for 
https://192.168.103.98/nfc/5201b6e8-5cc7-e7bf-dc30-1300dda05ae0/disk-0.vmdk. 
close /usr/lib/python2.7/dist-packages/oslo_vmware/rw_handles.py:466
<183>Dec 22 07:11:59 node-10 nova-compute: 2016-12-22 07:11:59.916 4011 DEBUG 
oslo_vmware.api [req-985a3617-9d0b-4ee7-926d-49e11578a811 
a0f3b1d5ef8842ac88e3ebd976685d88 9f7fc3501e654b0eb0166bf8be207044 - - -] 
Waiting for function oslo_vmware.api._invoke_api to return. func 
/usr/lib/python2.7/dist-packages/oslo_vmware/api.py:122
<183>Dec 22 07:12:03 node-10 nova-compute: 2016-12-22 07:12:03.842 4011 DEBUG 
oslo_vmware.rw_handles [req-985a3617-9d0b-4ee7-926d-49e11578a811 
a0f3b1d5ef8842ac88e3ebd976685d88 9f7fc3501e654b0eb0166bf8be207044 - - -] Closed 
VMDK write handle for 
https://192.168.103.98/nfc/5201b6e8-5cc7-e7bf-dc30-1300dda05ae0/disk-0.vmdk. 
close /usr/lib/python2.7/dist-packages/oslo_vmware/rw_handles.py:481
<183>Dec 22 07:12:03 node-10 nova-compute: 2016-12-22 07:12:03.843 4011 DEBUG 
oslo_concurrency.lockutils [req-985a3617-9d0b-4ee7-926d-49e11578a811 
a0f3b1d5ef8842ac88e3ebd976685d88 9f7fc3501e654b0eb0166bf8be207044 - - -] 
Releasing semaphore "[WYYVSANDATASTOR] 
vcenter-WyyCluster_base/121e0150-88a8-440f-9ce4-2f5a1bceae2d/121e0150-88a8-440f-9ce4-2f5a1bceae2d.vmdk"
 lock /usr/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:225
<179>Dec 22 07:12:03 node-10 nova-compute: 2016-12-22 07:12:03.844 4011 ERROR 
nova.compute.manager [req-985a3617-9d0b-4ee7-926d-49e11578a811 
a0f3b1d5ef8842ac88e3ebd976685d88 9f7fc3501e654b0eb0166bf8be207044 - - -] 
[instance: c6cea137-8a09-4960-bc01-8612a60fe250] Instance failed to spawn
2016-12-22 07:12:03.844 4011 ERROR nova.compute.manager [instance: 

[Yahoo-eng-team] [Bug 1649793] Re: vmware image download error

[YuYang]

** Changed in: nova
   Status: Incomplete => Invalid

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

Title:
  vmware image download error

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  when create vm in openstack success,then i task a snapshot from the vm
  ,and then use the snapshot to deploy vm error.

  i add some log in the code ,found write_handle only transfer several
  times ,will break off.

  the error msg:

  2016-12-14 03:37:20.138 26646 ERROR nova.virt.vmwareapi.images 
[req-d2899c45-97fc-4077-8b9d-b8152532f7c5 098673ebb2c54b6ea608b204ffaa82b7 
3885b586a8014286bc07b24df332afab - - -] ---write_handle.write 
1---
  2016-12-14 03:37:20.140 26646 ERROR nova.virt.vmwareapi.images 
[req-d2899c45-97fc-4077-8b9d-b8152532f7c5 098673ebb2c54b6ea608b204ffaa82b7 
3885b586a8014286bc07b24df332afab - - -] ---write_handle.write 
1---
  2016-12-14 03:37:20.142 26646 ERROR nova.virt.vmwareapi.images 
[req-d2899c45-97fc-4077-8b9d-b8152532f7c5 098673ebb2c54b6ea608b204ffaa82b7 
3885b586a8014286bc07b24df332afab - - -] ---write_handle.write 
1---
  2016-12-14 03:37:20.144 26646 ERROR nova.virt.vmwareapi.images 
[req-d2899c45-97fc-4077-8b9d-b8152532f7c5 098673ebb2c54b6ea608b204ffaa82b7 
3885b586a8014286bc07b24df332afab - - -] ---write_handle.write 
1---
  2016-12-14 03:37:20.464 26646 ERROR nova.virt.vmwareapi.images 
[req-d2899c45-97fc-4077-8b9d-b8152532f7c5 098673ebb2c54b6ea608b204ffaa82b7 
3885b586a8014286bc07b24df332afab - - -] ---write_handle.write 
1---
  2016-12-14 03:37:21.811 26646 ERROR nova.virt.vmwareapi.images 
[req-d2899c45-97fc-4077-8b9d-b8152532f7c5 098673ebb2c54b6ea608b204ffaa82b7 
3885b586a8014286bc07b24df332afab - - -] ---write_handle.write 
1---
  2016-12-14 03:37:42.449 26646 ERROR nova.virt.vmwareapi.images 
[req-d2899c45-97fc-4077-8b9d-b8152532f7c5 098673ebb2c54b6ea608b204ffaa82b7 
3885b586a8014286bc07b24df332afab - - -] ---write_handle.write 
1---
  2016-12-14 03:37:42.451 26646 ERROR nova.virt.vmwareapi.images 
[req-d2899c45-97fc-4077-8b9d-b8152532f7c5 098673ebb2c54b6ea608b204ffaa82b7 
3885b586a8014286bc07b24df332afab - - -] ---write_handle.write 
1---
  2016-12-14 03:37:42.508 26646 DEBUG oslo_vmware.rw_handles 
[req-d2899c45-97fc-4077-8b9d-b8152532f7c5 098673ebb2c54b6ea608b204ffaa82b7 
3885b586a8014286bc07b24df332afab - - -] Getting lease state for 
https://192.168.103.86/nfc/52c6f60a-50c4-e232-7659-b0927f1dd866/disk-0.vmdk. 
close /usr/lib/python2.7/dist-packages/oslo_vmware/rw_handles.py:459
  2016-12-14 03:37:42.509 26646 DEBUG oslo_vmware.rw_handles 
[req-d2899c45-97fc-4077-8b9d-b8152532f7c5 098673ebb2c54b6ea608b204ffaa82b7 
3885b586a8014286bc07b24df332afab - - -] --start 
close- close 
/usr/lib/python2.7/dist-packages/oslo_vmware/rw_handles.py:460
  2016-12-14 03:37:42.510 26646 DEBUG oslo_vmware.rw_handles 
[req-d2899c45-97fc-4077-8b9d-b8152532f7c5 098673ebb2c54b6ea608b204ffaa82b7 
3885b586a8014286bc07b24df332afab - - -] [(, 
'/usr/lib/python2.7/dist-packages/oslo_vmware/rw_handles.py', 461, 'close', ['  
  LOG.debug(inspect.stack())\n'], 0), (, 
'/usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/images.py', 208, 
'image_transfer', ['write_handle.close()\n'], 0), (, '/usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/images.py', 
359, 'fetch_image_stream_optimized', ['image_transfer(read_handle, 
write_handle)\n'], 0), (, 
'/usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/vmops.py', 429, 
'_fetch_image_as_vapp', ['self._root_resource_pool)\n'], 0), 
(, 
'/usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/vmops.py', 614, 
'_fetch_image_if_missing', ['im
 age_fetch(context, vi, tmp_image_ds_loc)\n'], 0), (, '/usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/vmops.py', 
751, 'spawn', ['self._fetch_image_if_missing(context, vi)\n'], 0), 
(, 
'/usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/driver.py', 381, 'spawn', 
['  admin_password, network_info, 
block_device_info)\n'], 0), (, 
'/usr/lib/python2.7/dist-packages/nova/compute/manager.py', 2064, 
'_build_and_run_instance', ['  
block_device_info=block_device_info)\n'], 0), (, 
'/usr/lib/python2.7/dist-packages/nova/compute/manager.py', 1926, 
'_do_build_and_run_instance', ['filter_properties)\n'], 
0), (, 
'/usr/lib/python2.7/dist-packages/nova/compute/manager.py', 375, 
'decorated_function', ['return function(self, context, *args, 
**kwargs)\n'], 
 0), (, 
'/usr/lib/python2.7/dist-packages/nova/compute/manager.py', 409, 
'decorated_function', ['return function(self, context,