date:20140908

Public bug reported:

[Feedback from translation] some short strings need contextual marker to
distinguish different meanings.

Started
- "Past tense of the action" in dashboards/project/instances/tables.py
- "Start time" in 
dashboards/project/data_processing/job_executions/templates/data_processing.job_executions/_details.html

'%s (Not Found)' in dashboards/project/routers/views.py
It is hard to understand for translators. It is better to add contextual 
markers and translator notes.

The following words is better to have contextual markers.
- Force in dashboards/project/volumes/volumes/forms.py
- Path in openstack_dashboard/dashboards/project/containers/forms.py (it needs 
to wrapped with ugettext first)

** Affects: horizon
 Importance: Medium
 Assignee: Akihiro Motoki (amotoki)
 Status: New


** Tags: i18n

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

Title:
  [Feedback from translation] some short strings need contextual marker
  to distinguish different meanings

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  [Feedback from translation] some short strings need contextual marker
  to distinguish different meanings.

  Started
  - "Past tense of the action" in dashboards/project/instances/tables.py
  - "Start time" in 
dashboards/project/data_processing/job_executions/templates/data_processing.job_executions/_details.html

  '%s (Not Found)' in dashboards/project/routers/views.py
  It is hard to understand for translators. It is better to add contextual 
markers and translator notes.

  The following words is better to have contextual markers.
  - Force in dashboards/project/volumes/volumes/forms.py
  - Path in openstack_dashboard/dashboards/project/containers/forms.py (it 
needs to wrapped with ugettext first)

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1367104/+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 1303682] Re: 'qg' interface associates with 'br-int' inetead of 'br-ext' when multiple external networks are created

2014-09-08 Thread Vinod Kumar

This issue is already addressed by https://review.openstack.org/#/c/59359/
Changing Bug Status to "Invalid".

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

Title:
  'qg' interface associates with 'br-int' inetead of 'br-ext' when
  multiple external networks are created

Status in OpenStack Neutron (virtual network service):
  Invalid

Bug description:
  This is with respect to Change Id260a239: L3 Agent can handle many
  external networks. (https://review.openstack.org/#/c/59359/)

  After this fix was introduced L3 Agent could handle the multiple
  external networks but the 'qg' interfaces were getting created under
  br-int instead of br-ext.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1303682/+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 1367103] [NEW] [Feedback from translation] Descriptions in some forms are not appropriate

Public bug reported:

Feedback from translations.
These are incorrect/inappropriate descriptions found during the translations.

dashboards/admin/networks/templates/networks/_create.html
Select a name for your network.
<--- It is a admin network creation form and it is different from the actual
forms.
It should be updated to describe what the actual admin net-create form has
like provider networks, external networks and shared network.

Volume Status Update form
Error_Deleting: dashboards/admin/volumes/snapshots/forms.py
Error Deleting: dashboards/admin/volumes/volumes/forms.py
Both are the labels of status and they should match.
I prefer to "Error Deleting".

dashboards/project/access_and_security/templates/access_and_security/security_groups/_create.html
Edit the security group to add and change the rules.
<--- It is a form to create security group. The description is not correct.

"network settings" vs "networking settings"
It seems "network settings" is better.
"network settings":
access_and_security/templates/access_and_security/security_groups/_create.html
"networking settings":
access_and_security/templates/access_and_security/security_groups/_update.html

dashboards/project/images/templates/images/images/_update.html
dashboards/admin/images/templates/images/_update.html
Modify different properties of an image. -> Edit the image details.

** Affects: horizon
Importance: Medium
Assignee: Akihiro Motoki (amotoki)
Status: New

** Tags: i18n

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

Title:
[Feedback from translation] Descriptions in some forms are not
appropriate

Status in OpenStack Dashboard (Horizon):
New

Bug description:
Feedback from translations.
These are incorrect/inappropriate descriptions found during the translations.

dashboards/project/images/templates/images/images/_update.html
dashboards/admin/images/templates/images/_update.html
Modify different properties of an image. -> Edit the image details.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1367103/+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 1367093] Re: "Upload Object" button is not enabled even when the object name is filled after the upload file is selected

** Attachment added: "upload-button-not-enabled.png"
   
https://bugs.launchpad.net/neutron/+bug/1367093/+attachment/4199357/+files/upload-button-not-enabled.png

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

** No longer affects: neutron

** Changed in: horizon
Milestone: None => juno-rc1

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

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

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

Title:
  "Upload Object" button is not enabled even when the object name is
  filled after the upload file is selected

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  In the object upload form, when a file to be uploaded is selected, the
  object name field is filled with the file name (as default), but at
  that time "Upload Object" button is still disabled.

  To enable "Upload Object" button, we need to edit the object name
  field at least by one character.

  Expected:
  "Upload Object" button should be enabled after a file to be uploaded is 
selected and the object name field is filled.
  It is a usual use case to use a name of the uploaded file as an object name, 
so it is nice to have "Upload Object" button enabled after a file is selected.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1367093/+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 1277104] Re: wrong order of assertEquals args

2014-09-08 Thread Dean Troyer

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

** Changed in: python-openstackclient
Milestone: m5 => None

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

Title:
  wrong order of assertEquals args

Status in OpenStack Telemetry (Ceilometer):
  Fix Released
Status in Cinder:
  In Progress
Status in OpenStack Image Registry and Delivery Service (Glance):
  In Progress
Status in OpenStack Identity (Keystone):
  Fix Released
Status in Messaging API for OpenStack:
  Fix Released
Status in Python client library for Ceilometer:
  In Progress
Status in Python client library for Glance:
  In Progress
Status in Python client library for Ironic:
  Fix Released
Status in Python client library for Nova:
  In Progress
Status in OpenStack Command Line Client:
  Fix Released
Status in Python client library for Swift:
  In Progress
Status in Rally:
  Confirmed

Bug description:
  Args of assertEquals method in ceilometer.tests are arranged in wrong order. 
In result when test fails it shows incorrect information about observed and 
actual data. It's found more than 2000 times.
  Right order of arguments is "expected, actual".

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1277104/+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 1367093] [NEW] "Upload Object" button is not enabled even when the object name is filled after the upload file is selected

Public bug reported:

In the object upload form, when a file to be uploaded is selected, the
object name field is filled with the file name (as default), but at that
time "Upload Object" button is still disabled.

To enable "Upload Object" button, we need to edit the object name field
at least by one character.

Expected:
"Upload Object" button should be enabled after a file to be uploaded is 
selected and the object name field is filled.
It is a usual use case to use a name of the uploaded file as an object name, so 
it is nice to have "Upload Object" button enabled after a file is selected.

** Affects: neutron
 Importance: Low
 Status: New


** Tags: swift

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

Title:
  "Upload Object" button is not enabled even when the object name is
  filled after the upload file is selected

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  In the object upload form, when a file to be uploaded is selected, the
  object name field is filled with the file name (as default), but at
  that time "Upload Object" button is still disabled.

  To enable "Upload Object" button, we need to edit the object name
  field at least by one character.

  Expected:
  "Upload Object" button should be enabled after a file to be uploaded is 
selected and the object name field is filled.
  It is a usual use case to use a name of the uploaded file as an object name, 
so it is nice to have "Upload Object" button enabled after a file is selected.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1367093/+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 1367091] [NEW] delimiter of Swift Container pseudo folder is DOUBLE slash

Public bug reported:

The delimiter of Swift Container pseudo folder in the Container table is
*two* slash. A single slash is sufficient.

** Affects: neutron
 Importance: Low
 Status: New


** Tags: swift

** Attachment added: "double-slash-as-delimiter.png"
   
https://bugs.launchpad.net/bugs/1367091/+attachment/4199353/+files/double-slash-as-delimiter.png

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

Title:
  delimiter of Swift Container pseudo folder is *DOUBLE* slash

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  The delimiter of Swift Container pseudo folder in the Container table
  is *two* slash. A single slash is sufficient.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1367091/+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 1367075] [NEW] iptables_manager.get_binary_name is broken with greenlet

2014-09-08 Thread YAMAMOTO Takashi

Public bug reported:

when imported by non-main thread, iptables_manager.get_binary_name yields 
something like "greenthread.py".
(it's actually the case for ofagent.)
it's considered broken as iptables_manager somehow assumes its uniqueness.

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

Title:
  iptables_manager.get_binary_name is broken with greenlet

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  when imported by non-main thread, iptables_manager.get_binary_name yields 
something like "greenthread.py".
  (it's actually the case for ofagent.)
  it's considered broken as iptables_manager somehow assumes its uniqueness.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1367075/+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 1367060] [NEW] nova network-create allows invalid fixed-ip creation

2014-09-08 Thread Dan Sneddon

Public bug reported:

Creating a network with 'nova network-create' allows the creation of
fixed-ips that fall outside the fixed-range-v4, resulting in invalid
fixed IPs.

To recreate:
Create a network with network-create that contains a fixed-cidr that falls 
outside the fixed-range-v4.

Actual outcome:
If the user runs the following command
nova network-create vmnet --fixed-range-v4 10.1.0.0/24 --fixed-cidr 
10.20.0.0/16 --bridge br-100

This command succeeds, and creates invalid fixed IPs which can be
retrieved with 'nova fixed-ip-get', for example:

nova fixed-ip-get 10.20.0.1

+---+-+--+--+
| address   | cidr| hostname | host |
+---+-+--+--+
| 10.20.0.1 | 10.1.0.0/24 | -| -|
+---+-+--+--+

This address falls outside the cidr, so is invalid.

Desired outcome:
Nova network-create should verify that the fixed-cidr is a subset of 
fixed-range-v4, if the fixed-cidr falls outside of the fixed-range-v4 the 
command should fail with an error, such as "ERROR: fixed-cidr must be a subset 
of fixed-range-v4".

** Affects: nova
 Importance: Undecided
 Status: New

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

Title:
  nova network-create allows invalid fixed-ip creation

Status in OpenStack Compute (Nova):
  New

Bug description:
  Creating a network with 'nova network-create' allows the creation of
  fixed-ips that fall outside the fixed-range-v4, resulting in invalid
  fixed IPs.

  To recreate:
  Create a network with network-create that contains a fixed-cidr that falls 
outside the fixed-range-v4.

  Actual outcome:
  If the user runs the following command
  nova network-create vmnet --fixed-range-v4 10.1.0.0/24 --fixed-cidr 
10.20.0.0/16 --bridge br-100

  This command succeeds, and creates invalid fixed IPs which can be
  retrieved with 'nova fixed-ip-get', for example:

  nova fixed-ip-get 10.20.0.1

  +---+-+--+--+
  | address   | cidr| hostname | host |
  +---+-+--+--+
  | 10.20.0.1 | 10.1.0.0/24 | -| -|
  +---+-+--+--+

  This address falls outside the cidr, so is invalid.

  Desired outcome:
  Nova network-create should verify that the fixed-cidr is a subset of 
fixed-range-v4, if the fixed-cidr falls outside of the fixed-range-v4 the 
command should fail with an error, such as "ERROR: fixed-cidr must be a subset 
of fixed-range-v4".

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1367060/+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 1367059] [NEW] When creating an image, --id option can't be set in v2 api

2014-09-08 Thread Haiwei Xu

Public bug reported:

When creating an image using '--id' option in v2 api, will get an error
like this:

$ glance  --os-image-api-version 2 image-create --id
459b20d0-e0b7-4715-bbc4-58a8d23e8236 --name test2 --container-format
bare --disk-format qcow2

  File "/usr/local/lib/python2.7/dist-packages/eventlet/wsgi.py", line 433, in 
handle_one_response
result = self.application(self.environ, start_response)
  File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 130, in 
__call__
resp = self.call_func(req, *args, **self.kwargs)
  File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 195, in 
call_func
return self.func(req, *args, **kwargs)
  File "/opt/stack/glance/glance/common/wsgi.py", line 394, in __call__
response = req.get_response(self.application)
  File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line 1320, in 
send
application, catch_exc_info=False)
  File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line 1284, in 
call_application
app_iter = application(self.environ, start_response)
  File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 130, in 
__call__
resp = self.call_func(req, *args, **self.kwargs)
  File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 195, in 
call_func
return self.func(req, *args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/osprofiler/web.py", line 106, in 
__call__
return request.get_response(self.application)
  File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line 1320, in 
send
application, catch_exc_info=False)
  File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line 1284, in 
call_application
app_iter = application(self.environ, start_response)
  File 
"/usr/local/lib/python2.7/dist-packages/keystonemiddleware/auth_token.py", line 
570, in __call__
return self._app(env, start_response)
  File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 130, in 
__call__
resp = self.call_func(req, *args, **self.kwargs)
  File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 195, in 
call_func
return self.func(req, *args, **kwargs)
  File "/opt/stack/glance/glance/common/wsgi.py", line 394, in __call__
response = req.get_response(self.application)
  File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line 1320, in 
send
application, catch_exc_info=False)
  File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line 1284, in 
call_application
app_iter = application(self.environ, start_response)
  File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 130, in 
__call__
resp = self.call_func(req, *args, **self.kwargs)
  File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 195, in 
call_func
return self.func(req, *args, **kwargs)
  File "/opt/stack/glance/glance/common/wsgi.py", line 394, in __call__
response = req.get_response(self.application)
  File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line 1320, in 
send
application, catch_exc_info=False)
  File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line 1284, in 
call_application
app_iter = application(self.environ, start_response)
  File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 130, in 
__call__
resp = self.call_func(req, *args, **self.kwargs)
  File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 195, in 
call_func
return self.func(req, *args, **kwargs)
  File "/opt/stack/glance/glance/common/wsgi.py", line 394, in __call__
response = req.get_response(self.application)
  File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line 1320, in 
send
application, catch_exc_info=False)
  File "/usr/local/lib/python2.7/dist-packages/webob/request.py", line 1284, in 
call_application
app_iter = application(self.environ, start_response)
  File "/usr/lib/python2.7/dist-packages/paste/urlmap.py", line 206, in __call__
return app(environ, start_response)
  File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 144, in 
__call__
return resp(environ, start_response)
  File "/usr/local/lib/python2.7/dist-packages/routes/middleware.py", line 131, 
in __call__
response = self.app(environ, start_response)
  File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 144, in 
__call__
return resp(environ, start_response)
  File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 130, in 
__call__
resp = self.call_func(req, *args, **self.kwargs)
  File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 195, in 
call_func
return self.func(req, *args, **kwargs)
  File "/opt/stack/glance/glance/common/wsgi.py", line 673, in __call__
request, **action_args)
  File "/opt/stack/glance/glance/common/wsgi.py", line 697, in dispatch
return method(*args, **kwargs)
  File "/opt/stack/glance/glance/common/utils.py", line 449, in wrapped
return fu

[Yahoo-eng-team] [Bug 1367007] Re: Ironic driver requires extra_specs

2014-09-08 Thread Michael Still

** Also affects: nova/juno
   Importance: High
 Assignee: Michael Davies (mrda)
   Status: In Progress

** Changed in: nova/juno
Milestone: None => juno-rc1

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

Title:
  Ironic driver requires extra_specs

Status in OpenStack Compute (Nova):
  In Progress
Status in OpenStack Compute (nova) juno series:
  In Progress

Bug description:
  Comments on review https://review.openstack.org/#/c/111429/ suggested
  that the Ironic driver should use

flavor = instance.get_flavor()

  instead of

flavor = flavor_obj.Flavor.get_by_id(context,
  instance['instance_type_id'])

  During the crunch to land things before feature freeze, these were
  integrated in the proposal to the Nova tree prior to being landed in
  the Ironic tree (the only place where they would have been tested).
  These changes actually broke the driver, since it requires access to
  flavor['extra_specs'] -- which is not present in the instance's cached
  copy of the flavor.

  This problem was discovered when attempting to update the devstack
  config and begin testing with the driver from the Nova tree (rather
  than the copy of the driver in the Ironic tree). That patch is here:

  https://review.openstack.org/#/c/119844/

  The error being encountered can be seen both on the devstack patch
  (eg, in the Nova code)

  http://logs.openstack.org/44/119844/2/check/check-tempest-dsvm-
  virtual-ironic-nv/ce443f8/logs/screen-n-cpu.txt.gz

  and in the back-port of the same code to Ironic here:

  http://logs.openstack.org/65/119165/3/check/check-tempest-dsvm-
  virtual-
  ironic/c161a89/logs/screen-n-cpu.txt.gz#_2014-09-08_08_41_06_821

  
  ==
  Proposed fix
  ==

  Fetch flavor['extra_specs'] on demand, when needed by the Ironic
  driver.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1367007/+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 1350766] Re: Race condition: compute intermittently corrupts base images on download from glance

2014-09-08 Thread Jeremy Stanley

I've marked the OSSA task as "won't fix" to indicate this issue isn't
one for which the project vulnerability management team would publish a
coordinated security advisory, as the conditions by which it is
triggered do not seem to be under direct control of a malicious actor
but rather one of volume and statistical happenstance. This does
definitely still sound like an annoying bug, however, and one which the
Nova developers will hopefully address in a timely manner.

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

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

Title:
  Race condition: compute intermittently corrupts base images on
  download from glance

Status in OpenStack Compute (Nova):
  In Progress
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Under certain conditions, which I happen to meet often on my Icehouse
  single node setup, uploaded images or snapshots fail to boot. See also
  https://ask.openstack.org/en/question/42804/icehouse-how-to-boot-a
  -snapshot-from-a-running-instance/

  Reason: When first instantiating a QCOW2 image, it's

  (1)  downloaded as QCOW2 to /var/lib/nova/instances/_base/IMAGEID.part
  (2)  converted to RAW format base 
/var/lib/nova/instances/_base/IMAGEID.converted using qemu-img

  The step (1) is performed in nova/image/glance.py,
  GlanceImageService.download using buffered IO, which does not
  guarantee the resulting data to be written to disk on file close.
  Consequently, the source image file may not be written completely when
  qemu-img sub-process starts reading in step (2). Whether the result is
  good or bad depends on speed of download, file size, and how quickly
  qemu-image can digest its input.

  Proposed fix: enforce fsync on output File object before returning
  from download. Patch attached.

  Security considerations:

   * Due to the race between resources shared between users and tenants
  (compute node network and filesystem IO) a failure can be triggered
  across tenants, implying the risk of DoS.

   * To make things worse -- with the default setting of not cleaning
  the image cache -- any corrupted image will remain in cache until
  replaced with fresh upload using a new image ID. Affected snapshots
  remain unusable forever, until ex- and re-imported manually under
  better conditions.

   * Base image corruptions here are not detected and cannot be caught.
  Theoretically (a bit esoteric, quite unlikely, but not impossible), an
  attacker might modulate resource usage to precisely create an
  incompletely written image, that boots and runs, but has access
  control information stripped.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1350766/+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 1367039] [NEW] dvr fips are not handled properly on l3-agent restart

2014-09-08 Thread Mike Smith

Public bug reported:

When the l3-agent is restarted, the local variables self.agent_fip_count
and ri.dist_fip_count are not properly initialized.  Current namespaces
and fips are not counted so the variables are initialized to 0.  This
will result in unwanted behavior like stale  or duplicate fg ports or
fip namespaces.

** Affects: neutron
 Importance: Medium
 Assignee: Mike Smith (michael-smith6)
 Status: New


** Tags: l3-dvr-backlog

** Tags added: l3-dvr-backlog

** Changed in: neutron
 Assignee: (unassigned) => Mike Smith (michael-smith6)

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

Title:
  dvr fips are not handled properly on l3-agent restart

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  When the l3-agent is restarted, the local variables
  self.agent_fip_count and ri.dist_fip_count are not properly
  initialized.  Current namespaces and fips are not counted so the
  variables are initialized to 0.  This will result in unwanted behavior
  like stale  or duplicate fg ports or fip namespaces.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1367039/+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 1367036] [NEW] [Swift]:Deleting non Empty folder gives success pop up message.

2014-09-08 Thread Amogh

Public bug reported:

1. Login to Devstack
2. Create the Container "test1"
3. Create Pseudo Folder under "test1" and upload objects.
4. Go to pseudo folder  and selct "test1" , click on delete objects
5. Observe that "Success: Deleted Object: test1" message is displayed, However 
the folder is not deleted.

** Affects: horizon
 Importance: Undecided
 Status: New

** Attachment added: "Delete-Container.PNG"
   
https://bugs.launchpad.net/bugs/1367036/+attachment/4199152/+files/Delete-Container.PNG

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

Title:
  [Swift]:Deleting non Empty folder gives success pop up message.

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  1. Login to Devstack
  2. Create the Container "test1"
  3. Create Pseudo Folder under "test1" and upload objects.
  4. Go to pseudo folder  and selct "test1" , click on delete objects
  5. Observe that "Success: Deleted Object: test1" message is displayed, 
However the folder is not deleted.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1367036/+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 1367034] [NEW] NSX: prevents creating multiple networks same vlan but different physical network

Public bug reported:

NSX: prevents creating multiple networks same vlan but different
physical network

** Affects: neutron
 Importance: Undecided
 Assignee: Aaron Rosen (arosen)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) => Aaron Rosen (arosen)

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

Title:
  NSX: prevents creating multiple networks same vlan but different
  physical network

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  NSX: prevents creating multiple networks same vlan but different
  physical network

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1367034/+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 1367032] [NEW] NSX: unabled to delete provider network

Public bug reported:

2014-09-08 14:56:29.981 TRACE neutron.api.v2.resource 
2014-09-08 14:59:52.729 ERROR oslo.db.sqlalchemy.exc_filters 
[req-95d62444-0b6f-4710-93f1-c5718b257762 admin 
236c7a84a5b24a5b93053b9649e09b47] DBAPIError exception wrapped from 
(IntegrityError) (1451, 'Cannot delete or update a parent row: a foreign key 
constraint fails (`neutron`.`tz_network_bindings`, CONSTRAINT 
`tz_network_bindings_ibfk_1` FOREIGN KEY (`network_id`) REFERENCES `networks` 
(`id`))') 'DELETE FROM networks WHERE networks.id = %s' 
('7e6f7301-faf8-4e7b-b635-1f91d22aa955',)
2014-09-08 14:59:52.729 TRACE oslo.db.sqlalchemy.exc_filters Traceback (most 
recent call last):
2014-09-08 14:59:52.729 TRACE oslo.db.sqlalchemy.exc_filters   File 
"/usr/local/lib/python2.7/dist-packages/oslo/db/sqlalchemy/compat/handle_error.py",
 line 59, in _handle_dbapi_exception
2014-09-08 14:59:52.729 TRACE oslo.db.sqlalchemy.exc_filters e, statement, 
parameters, cursor, context)
2014-09-08 14:59:52.729 TRACE oslo.db.sqlalchemy.exc_filters   File 
"/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1024, in 
_handle_dbapi_exception
2014-09-08 14:59:52.729 TRACE oslo.db.sqlalchemy.exc_filters exc_info
2014-09-08 14:59:52.729 TRACE oslo.db.sqlalchemy.exc_filters   File 
"/usr/lib/python2.7/dist-packages/sqlalchemy/util/compat.py", line 196, in 
raise_from_cause
2014-09-08 14:59:52.729 TRACE oslo.db.sqlalchemy.exc_filters 
reraise(type(exception), exception, tb=exc_tb)
2014-09-08 14:59:52.729 TRACE oslo.db.sqlalchemy.exc_filters   File 
"/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 867, in 
_execute_context
2014-09-08 14:59:52.729 TRACE oslo.db.sqlalchemy.exc_filters context)
2014-09-08 14:59:52.729 TRACE oslo.db.sqlalchemy.exc_filters   File 
"/usr/lib/python2.7/dist-packages/sqlalchemy/engine/default.py", line 324, in 
do_execute
2014-09-08 14:59:52.729 TRACE oslo.db.sqlalchemy.exc_filters 
cursor.execute(statement, parameters)
2014-09-08 14:59:52.729 TRACE oslo.db.sqlalchemy.exc_filters   File 
"/usr/lib/python2.7/dist-packages/MySQLdb/cursors.py", line 174, in execute
2014-09-08 14:59:52.729 TRACE oslo.db.sqlalchemy.exc_filters 
self.errorhandler(self, exc, value)
2014-09-08 14:59:52.729 TRACE oslo.db.sqlalchemy.exc_filters   File 
"/usr/lib/python2.7/dist-packages/MySQLdb/connections.py", line 36, in 
defaulterrorhandler
2014-09-08 14:59:52.729 TRACE oslo.db.sqlalchemy.exc_filters raise 
errorclass, errorvalue
2014-09-08 14:59:52.729 TRACE oslo.db.sqlalchemy.exc_filters IntegrityError: 
(IntegrityError) (1451, 'Cannot delete or update a parent row: a foreign key 
constraint fails (`neutron`.`tz_network_bindings`, CONSTRAINT 
`tz_network_bindings_ibfk_1` FOREIGN KEY (`network_id`) REFERENCES `networks` 
(`id`))') 'DELETE FROM networks WHERE networks.id = %s' 
('7e6f7301-faf8-4e7b-b635-1f91d22aa955',)
2014-09-08 14:59:52.729 TRACE oslo.db.sqlalchemy.exc_filters 
2014-09-08 14:59:52.804 ERROR neutron.api.v2.resource 
[req-95d62444-0b6f-4710-93f1-c5718b257762 admin 
236c7a84a5b24a5b93053b9649e09b47] delete failed
2014-09-08 14:59:52.804 TRACE neutron.api.v2.resource Traceback (most recent 
call last):
2014-09-08 14:59:52.804 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/api/v2/resource.py", line 87, in resource
2014-09-08 14:59:52.804 TRACE neutron.api.v2.resource result = 
method(request=request, **args)
2014-09-08 14:59:52.804 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/api/v2/base.py", line 476, in delete
2014-09-08 14:59:52.804 TRACE neutron.api.v2.resource 
obj_deleter(request.context, id, **kwargs)
2014-09-08 14:59:52.804 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/plugins/vmware/plugins/base.py", line 1005, in 
delete_network
2014-09-08 14:59:52.804 TRACE neutron.api.v2.resource super(NsxPluginV2, 
self).delete_network(context, id)
2014-09-08 14:59:52.804 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/db/db_base_plugin_v2.py", line 912, in 
delete_network
2014-09-08 14:59:52.804 TRACE neutron.api.v2.resource 
context.session.delete(network)
2014-09-08 14:59:52.804 TRACE neutron.api.v2.resource   File 
"/usr/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 447, in 
__exit__
2014-09-08 14:59:52.804 TRACE neutron.api.v2.resource self.rollback()
2014-09-08 14:59:52.804 TRACE neutron.api.v2.resource   File 
"/usr/lib/python2.7/dist-packages/sqlalchemy/util/langhelpers.py", line 58, in 
__exit__
2014-09-08 14:59:52.804 TRACE neutron.api.v2.resource 
compat.reraise(exc_type, exc_value, exc_tb)
2014-09-08 14:59:52.804 TRACE neutron.api.v2.resource   File 
"/usr/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 444, in 
__exit__
2014-09-08 14:59:52.804 TRACE neutron.api.v2.resource self.commit()
2014-09-08 14:59:52.804 TRACE neutron.api.v2.resource   File 
"/usr/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 354, in 
commit
2014

[Yahoo-eng-team] [Bug 1367007] [NEW] Ironic driver requires extra_specs

2014-09-08 Thread Devananda van der Veen

Public bug reported:

Comments on review https://review.openstack.org/#/c/111429/ suggested
that the Ironic driver should use

  flavor = instance.get_flavor()

instead of

  flavor = flavor_obj.Flavor.get_by_id(context,
instance['instance_type_id'])

During the crunch to land things before feature freeze, these were
integrated in the proposal to the Nova tree prior to being landed in the
Ironic tree (the only place where they would have been tested). These
changes actually broke the driver, since it requires access to
flavor['extra_specs'] -- which is not present in the instance's cached
copy of the flavor.

This problem was discovered when attempting to update the devstack
config and begin testing with the driver from the Nova tree (rather than
the copy of the driver in the Ironic tree). That patch is here:

https://review.openstack.org/#/c/119844/

The error being encountered can be seen both on the devstack patch (eg,
in the Nova code)

http://logs.openstack.org/44/119844/2/check/check-tempest-dsvm-virtual-
ironic-nv/ce443f8/logs/screen-n-cpu.txt.gz

and in the back-port of the same code to Ironic here:

http://logs.openstack.org/65/119165/3/check/check-tempest-dsvm-virtual-
ironic/c161a89/logs/screen-n-cpu.txt.gz#_2014-09-08_08_41_06_821


==
Proposed fix
==

Fetch flavor['extra_specs'] on demand, when needed by the Ironic driver.

** Affects: nova
 Importance: Undecided
 Assignee: Devananda van der Veen (devananda)
 Status: New

** Changed in: nova
 Assignee: (unassigned) => Devananda van der Veen (devananda)

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

Title:
  Ironic driver requires extra_specs

Status in OpenStack Compute (Nova):
  New

Bug description:
  Comments on review https://review.openstack.org/#/c/111429/ suggested
  that the Ironic driver should use

flavor = instance.get_flavor()

  instead of

flavor = flavor_obj.Flavor.get_by_id(context,
  instance['instance_type_id'])

  During the crunch to land things before feature freeze, these were
  integrated in the proposal to the Nova tree prior to being landed in
  the Ironic tree (the only place where they would have been tested).
  These changes actually broke the driver, since it requires access to
  flavor['extra_specs'] -- which is not present in the instance's cached
  copy of the flavor.

  This problem was discovered when attempting to update the devstack
  config and begin testing with the driver from the Nova tree (rather
  than the copy of the driver in the Ironic tree). That patch is here:

  https://review.openstack.org/#/c/119844/

  The error being encountered can be seen both on the devstack patch
  (eg, in the Nova code)

  http://logs.openstack.org/44/119844/2/check/check-tempest-dsvm-
  virtual-ironic-nv/ce443f8/logs/screen-n-cpu.txt.gz

  and in the back-port of the same code to Ironic here:

  http://logs.openstack.org/65/119165/3/check/check-tempest-dsvm-
  virtual-
  ironic/c161a89/logs/screen-n-cpu.txt.gz#_2014-09-08_08_41_06_821

  
  ==
  Proposed fix
  ==

  Fetch flavor['extra_specs'] on demand, when needed by the Ironic
  driver.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1367007/+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 1367010] [NEW] [Sahara] ID's on job execution page can be replaced with clickable names

2014-09-08 Thread Andrew Lazarev

Public bug reported:

Now Job Execution page contains a lot of ID's. They should be replaced
by clickable names.

** Affects: horizon
 Importance: Undecided
 Assignee: Andrew Lazarev (alazarev)
 Status: New

** Changed in: horizon
 Assignee: (unassigned) => Andrew Lazarev (alazarev)

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

Title:
  [Sahara] ID's on job execution page can be replaced with clickable
  names

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Now Job Execution page contains a lot of ID's. They should be replaced
  by clickable names.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1367010/+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 1367011] [NEW] glance-manage db_export_metadefs should always require a directory option

2014-09-08 Thread Travis Tripp

Public bug reported:

Currently if you call glance-manage db_export_metadefs without any
additional options, it will export all current metadefs into the glance
conf dir (e.g. /etc/glance/metadefs/) without any warning. If the files
already exist it will overwrite them. This is a potentially very
dangerous operation that would delete all the existing files in that
directory without warning and with no way of getting them back. A new
user may just call it hoping to see the parameters and instead end up
having all their files overwritten whether they want to or not.

I think that db_export_metadefs should always require a parameter of the
output directory to save them to. Either that or export them to a safer
location by default. Would like additional input from Glance team on
this one.

Example:

$ glance-manage db_export_metadefs

2014-09-08 16:11:15.865 5029 DEBUG oslo.db.sqlalchemy.session [-] MySQL
server mode set to
STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
_init_events /usr/local/lib/python2.7/dist-
packages/oslo/db/sqlalchemy/session.py:461

2014-09-08 16:11:15.900 5029 INFO glance.db.sqlalchemy.metadata [-]
Namespace RandomNumberGenerator saved in
/etc/glance/metadefs/RandomNumberGenerator.json

2014-09-08 16:11:15.910 5029 INFO glance.db.sqlalchemy.metadata [-]
Namespace VirtualCPUTopology saved in
/etc/glance/metadefs/VirtualCPUTopology.json

etc...

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

Title:
glance-manage db_export_metadefs should always require a directory
option

Status in OpenStack Image Registry and Delivery Service (Glance):
New

Bug description:
Currently if you call glance-manage db_export_metadefs without any
additional options, it will export all current metadefs into the
glance conf dir (e.g. /etc/glance/metadefs/) without any warning. If
the files already exist it will overwrite them. This is a potentially
very dangerous operation that would delete all the existing files in
that directory without warning and with no way of getting them back. A
new user may just call it hoping to see the parameters and instead end
up having all their files overwritten whether they want to or not.

I think that db_export_metadefs should always require a parameter of
the output directory to save them to. Either that or export them to a
safer location by default. Would like additional input from Glance
team on this one.

Example:

$ glance-manage db_export_metadefs

2014-09-08 16:11:15.865 5029 DEBUG oslo.db.sqlalchemy.session [-]
MySQL server mode set to

STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
_init_events /usr/local/lib/python2.7/dist-
packages/oslo/db/sqlalchemy/session.py:461

2014-09-08 16:11:15.900 5029 INFO glance.db.sqlalchemy.metadata [-]
Namespace RandomNumberGenerator saved in
/etc/glance/metadefs/RandomNumberGenerator.json

2014-09-08 16:11:15.910 5029 INFO glance.db.sqlalchemy.metadata [-]
Namespace VirtualCPUTopology saved in
/etc/glance/metadefs/VirtualCPUTopology.json

etc...

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1367011/+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 1366911] Re: Nova does not ensure a valid token is available if snapshot process exceeds token lifetime

2014-09-08 Thread Nikolay Starodubtsev

** Project changed: nova => keystone

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

Title:
  Nova does not ensure a valid token is available if snapshot process
  exceeds token lifetime

Status in OpenStack Identity (Keystone):
  New

Bug description:
  Recently we encountered the following issue due to the change in
  Icehouse for the default lifetime of a token before it expires. It's
  now 1 hour, while previously it was 8.

  If a snapshot process takes longer than an hour, when it goes to the
  next phase it will fail with a 401 Unauthorized error because it has
  an invalid token.

  In our specific example the following would take place:

  1. User would set a snapshot to begin and a token would be associated with 
this request.
  2. Snapshot would be created, compression time would take about 55 minutes. 
Enough to just push the snapshotting of this instance over the 60 minute mark.
  3. Upon Image Upload ("Uploading image data for image" in the logs) Nova 
would then return a 401 Unauthorized error stating "This server could not 
verify that you are authorized to access the document you requested. Either you 
supplied the wrong credentials (e.g., bad password), or your browser does not 
understand how to supply the credentials required."

  Icehouse 2014.1.2, KVM as the hypervisor.

  The workaround is to specify a longer token timeout - however limits
  the ability to set short token expirations.

  A possible solution may be to get a new/refresh the token if the time
  has exceeded the timeout.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1366911/+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 1366991] [NEW] Keystone local authenticate has unnecessary CADF pending audit record

2014-09-08 Thread Brad Topol

Public bug reported:

Keystone local authenticate has  an unnecessary CADF pending audit
record.  Pending should be used for long running operations but local
authenticate is not such an operation.  Keystone federated identity
authenticate audit record does not generate pending audit records so
fixing local authenticate will improve consistency

** Affects: keystone
 Importance: Undecided
 Assignee: Brad Topol (btopol)
 Status: New

** Changed in: keystone
 Assignee: (unassigned) => Brad Topol (btopol)

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

Title:
  Keystone local authenticate has unnecessary CADF pending audit record

Status in OpenStack Identity (Keystone):
  New

Bug description:
  Keystone local authenticate has  an unnecessary CADF pending audit
  record.  Pending should be used for long running operations but local
  authenticate is not such an operation.  Keystone federated identity
  authenticate audit record does not generate pending audit records so
  fixing local authenticate will improve consistency

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1366991/+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 1366988] [NEW] Formatting error in debug logging

2014-09-08 Thread David Stanek

Public bug reported:

When logging is set to the debug level revoke_token can fail when there
is not audit_chain_id, but the token is supposed to be revoked by the
chain.

** Affects: keystone
 Importance: Undecided
 Assignee: David Stanek (dstanek)
 Status: In Progress

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

Title:
  Formatting error in debug logging

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  When logging is set to the debug level revoke_token can fail when
  there is not audit_chain_id, but the token is supposed to be revoked
  by the chain.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1366988/+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 1355919] Re: By default when caching is enabled, objects will be cached forever

2014-09-08 Thread Morgan Fainberg

I did a bit more research, dogpile is handling this based upon the
[cache] expiration_time option.

https://github.com/openstack/keystone/blob/249d83529af0c746c6980aa0dbd2287bc8de345e/keystone/common/config.py#L293-L297

Which is set at the cache region level. If the decorator receives None as the
expiration time.
https://bitbucket.org/zzzeek/dogpile.cache/src/1c753914b335b4391bc5847a87b7c52ca81c2bc6/dogpile/cache/region.py#cl-663
called via the decorator:
https://bitbucket.org/zzzeek/dogpile.cache/src/1c753914b335b4391bc5847a87b7c52ca81c2bc6/dogpile/cache/region.py#cl-960

** Changed in: keystone
Status: In Progress => Invalid

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

Title:
By default when caching is enabled, objects will be cached forever

Status in OpenStack Identity (Keystone):
Invalid

Bug description:
The `cache_time` setting for the assignments, catalogs and tokens is
currently set to None by default. This means that if caching is
enabled for one of those subsystems and the operator did not specify
their own timeout the data will not automatically expire.

We are doing invalidation when data changes, at least in some cases.
I'm not sure that it's safe to say that anytime the data changes we
are correctly invaliding the key. We should strive to do this as it's
the right thing to do, but we should also have a default timeout so
that things we miss will not slip through.

I believe 10 minutes is a reasonable default for most things so I'll
provide a patch with that as the value. When I read `cache_time` I
see "the only acceptable amount of time to accept stale data".
Usually this is determined base on the information being cached, but
we currently only have the ability to set this at the subsystem level.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1355919/+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 1366982] [NEW] Exception NoMoreFixedIps doesn't show which network is out of IPs

2014-09-08 Thread Drew Thorstensen

Public bug reported:

The exception NoMoreFixedIps in nova/exception.py has a very generic error 
message:
"Zero fixed ips available."

When performing a deploy with multiple networks, it can become difficult
to determine which network has been exhausted.  Slight modification to
this error message will help simplify the debug process for operators.

** Affects: nova
 Importance: Undecided
 Assignee: Drew Thorstensen (thorst)
 Status: New

** Changed in: nova
 Assignee: (unassigned) => Drew Thorstensen (thorst)

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

Title:
  Exception NoMoreFixedIps doesn't show which network is out of IPs

Status in OpenStack Compute (Nova):
  New

Bug description:
  The exception NoMoreFixedIps in nova/exception.py has a very generic error 
message:
  "Zero fixed ips available."

  When performing a deploy with multiple networks, it can become
  difficult to determine which network has been exhausted.  Slight
  modification to this error message will help simplify the debug
  process for operators.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1366982/+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 1366973] [NEW] Should use "project" over "tenant" in visible strings

Public bug reported:

In OpenStack Dashboard, we use "Project" rather than "Tenant".
Only a few string with "tenant" are remaining.

dashboards/admin/metering/views.py
dashboards/project/data_processing/data_sources/templates/data_processing.data_sources/_details.html
dashboards/project/data_processing/jobs/templates/data_processing.jobs/_details.html
dashboards/project/loadbalancers/templates/loadbalancers/_updatepool.html
dashboards/router/nexus1000v/forms.py

** Affects: horizon
 Importance: Low
 Assignee: Akihiro Motoki (amotoki)
 Status: In Progress


** Tags: i18n ux

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

Title:
  Should use "project" over "tenant" in visible strings

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  In OpenStack Dashboard, we use "Project" rather than "Tenant".
  Only a few string with "tenant" are remaining.

  dashboards/admin/metering/views.py
  
dashboards/project/data_processing/data_sources/templates/data_processing.data_sources/_details.html
  
dashboards/project/data_processing/jobs/templates/data_processing.jobs/_details.html
  dashboards/project/loadbalancers/templates/loadbalancers/_updatepool.html
  dashboards/router/nexus1000v/forms.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1366973/+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 1366972] [NEW] Should use "project" over "tenant" in visible strings

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

Public bug reported:

In OpenStack Dashboard, we use "Project" rather than "Tenant".

** Affects: horizon
 Importance: Undecided
 Assignee: amo (amo)
 Status: New


** Tags: i18n ux

** This bug has been marked a duplicate of bug 1366973
   Should use "project" over "tenant" in visible strings

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

Title:
  Should use "project" over "tenant" in visible strings

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  In OpenStack Dashboard, we use "Project" rather than "Tenant".

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1366972/+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 1366931] Re: libvirtError: internal error: process exited while connecting to monitor: Cannot set up guest memory 'pc.ram': Cannot allocate memory

2014-09-08 Thread Matt Riedemann

Yeah saw that myself, removing ceilometer.

** No longer affects: ceilometer

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

Title:
  libvirtError: internal error: process exited while connecting to
  monitor: Cannot set up guest memory 'pc.ram': Cannot allocate memory

Status in OpenStack Compute (Nova):
  Confirmed

Bug description:
  http://logs.openstack.org/41/116741/5/gate/gate-grenade-
  dsvm/7064ee5/logs/old/screen-n-cpu.txt.gz?level=TRACE#_2014-09-07_02_27_10_408

  Libvirt stacktrace in n-cpu:

   Traceback (most recent call last):
     File "/opt/stack/old/nova/nova/compute/manager.py", line 1329, in 
_build_instance
   set_access_ip=set_access_ip)
     File "/opt/stack/old/nova/nova/compute/manager.py", line 393, in 
decorated_function
   return function(self, context, *args, **kwargs)
     File "/opt/stack/old/nova/nova/compute/manager.py", line 1741, in _spawn
   LOG.exception(_('Instance failed to spawn'), instance=instance)
     File "/opt/stack/old/nova/nova/openstack/common/excutils.py", line 68, in 
__exit__
   six.reraise(self.type_, self.value, self.tb)
     File "/opt/stack/old/nova/nova/compute/manager.py", line 1738, in _spawn
   block_device_info)
     File "/opt/stack/old/nova/nova/virt/libvirt/driver.py", line 2286, in spawn
   block_device_info)
     File "/opt/stack/old/nova/nova/virt/libvirt/driver.py", line 3686, in 
_create_domain_and_network
   power_on=power_on)
     File "/opt/stack/old/nova/nova/virt/libvirt/driver.py", line 3588, in 
_create_domain
   domain.XMLDesc(0))
     File "/opt/stack/old/nova/nova/openstack/common/excutils.py", line 68, in 
__exit__
   six.reraise(self.type_, self.value, self.tb)
     File "/opt/stack/old/nova/nova/virt/libvirt/driver.py", line 3583, in 
_create_domain
   domain.createWithFlags(launch_flags)
     File "/usr/lib/python2.7/dist-packages/eventlet/tpool.py", line 179, in 
doit
   result = proxy_call(self._autowrap, f, *args, **kwargs)
     File "/usr/lib/python2.7/dist-packages/eventlet/tpool.py", line 139, in 
proxy_call
   rv = execute(f,*args,**kwargs)
     File "/usr/lib/python2.7/dist-packages/eventlet/tpool.py", line 77, in 
tworker
   rv = meth(*args,**kwargs)
     File "/usr/lib/python2.7/dist-packages/libvirt.py", line 896, in 
createWithFlags
   if ret == -1: raise libvirtError ('virDomainCreateWithFlags() failed', 
dom=self)
   libvirtError: internal error: process exited while connecting to monitor: 
Cannot set up guest memory 'pc.ram': Cannot allocate memory

  query: message:"Cannot set up guest memory 'pc.ram': Cannot allocate
  memory" AND tags:"screen-n-cpu.txt"  AND  tags:"multiline"

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1366931/+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 1366944] [NEW] Man pages out of date

2014-09-08 Thread Brant Knudson

Public bug reported:

The man pages for keystone-all and keystone-manage are out of date.
especially keystone-manage is missing new subcommands.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 Status: New

** Changed in: keystone
 Assignee: (unassigned) => Brant Knudson (blk-u)

** Changed in: keystone
Milestone: None => juno-rc1

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

Title:
  Man pages out of date

Status in OpenStack Identity (Keystone):
  New

Bug description:
  The man pages for keystone-all and keystone-manage are out of date.
  especially keystone-manage is missing new subcommands.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1366944/+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 1366931] Re: ibvirtError: internal error: process exited while connecting to monitor: Cannot set up guest memory 'pc.ram': Cannot allocate memory

2014-09-08 Thread Matt Riedemann

http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwibGlidmlydEVycm9yOiBpbnRlcm5hbCBlcnJvcjogcHJvY2VzcyBleGl0ZWQgd2hpbGUgY29ubmVjdGluZyB0byBtb25pdG9yOiBDYW5ub3Qgc2V0IHVwIGd1ZXN0IG1lbW9yeSAncGMucmFtJzogQ2Fubm90IGFsbG9jYXRlIG1lbW9yeVwiIEFORCB0YWdzOlwic2NyZWVuLW4tY3B1LnR4dFwiIiwiZmllbGRzIjpbXSwib2Zmc2V0IjowLCJ0aW1lZnJhbWUiOiI2MDQ4MDAiLCJncmFwaG1vZGUiOiJjb3VudCIsInRpbWUiOnsidXNlcl9pbnRlcnZhbCI6MH0sInN0YW1wIjoxNDEwMjAyMjkxNzQyfQ==

18 hits in 7 days, check and gate, grenade jobs also (icehouse side),
all failures.

The name of the instance when this fails is
TelemetryNotificationAPITestJSON so it appears related to ceilometer
hitting the nova API too hard and causing out of memory (but there are
other related bugs for out of memory, I think related to neutron).

Can we rate limit ceilometer hitting the nova API in test?  For Tempest
runs we have disabled rate limiting for the nova v2 API since Havana.

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

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

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

Title:
  libvirtError: internal error: process exited while connecting to
  monitor: Cannot set up guest memory 'pc.ram': Cannot allocate memory

Status in OpenStack Telemetry (Ceilometer):
  New
Status in OpenStack Compute (Nova):
  Confirmed

Bug description:
  http://logs.openstack.org/41/116741/5/gate/gate-grenade-
  dsvm/7064ee5/logs/old/screen-n-cpu.txt.gz?level=TRACE#_2014-09-07_02_27_10_408

  Libvirt stacktrace in n-cpu:

   Traceback (most recent call last):
     File "/opt/stack/old/nova/nova/compute/manager.py", line 1329, in 
_build_instance
   set_access_ip=set_access_ip)
     File "/opt/stack/old/nova/nova/compute/manager.py", line 393, in 
decorated_function
   return function(self, context, *args, **kwargs)
     File "/opt/stack/old/nova/nova/compute/manager.py", line 1741, in _spawn
   LOG.exception(_('Instance failed to spawn'), instance=instance)
     File "/opt/stack/old/nova/nova/openstack/common/excutils.py", line 68, in 
__exit__
   six.reraise(self.type_, self.value, self.tb)
     File "/opt/stack/old/nova/nova/compute/manager.py", line 1738, in _spawn
   block_device_info)
     File "/opt/stack/old/nova/nova/virt/libvirt/driver.py", line 2286, in spawn
   block_device_info)
     File "/opt/stack/old/nova/nova/virt/libvirt/driver.py", line 3686, in 
_create_domain_and_network
   power_on=power_on)
     File "/opt/stack/old/nova/nova/virt/libvirt/driver.py", line 3588, in 
_create_domain
   domain.XMLDesc(0))
     File "/opt/stack/old/nova/nova/openstack/common/excutils.py", line 68, in 
__exit__
   six.reraise(self.type_, self.value, self.tb)
     File "/opt/stack/old/nova/nova/virt/libvirt/driver.py", line 3583, in 
_create_domain
   domain.createWithFlags(launch_flags)
     File "/usr/lib/python2.7/dist-packages/eventlet/tpool.py", line 179, in 
doit
   result = proxy_call(self._autowrap, f, *args, **kwargs)
     File "/usr/lib/python2.7/dist-packages/eventlet/tpool.py", line 139, in 
proxy_call
   rv = execute(f,*args,**kwargs)
     File "/usr/lib/python2.7/dist-packages/eventlet/tpool.py", line 77, in 
tworker
   rv = meth(*args,**kwargs)
     File "/usr/lib/python2.7/dist-packages/libvirt.py", line 896, in 
createWithFlags
   if ret == -1: raise libvirtError ('virDomainCreateWithFlags() failed', 
dom=self)
   libvirtError: internal error: process exited while connecting to monitor: 
Cannot set up guest memory 'pc.ram': Cannot allocate memory

  query: message:"Cannot set up guest memory 'pc.ram': Cannot allocate
  memory" AND tags:"screen-n-cpu.txt"  AND  tags:"multiline"

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1366931/+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 1366931] [NEW] libvirtError: internal error: process exited while connecting to monitor: Cannot set up guest memory 'pc.ram': Cannot allocate memory

2014-09-08 Thread Joe Gordon

Public bug reported:

http://logs.openstack.org/41/116741/5/gate/gate-grenade-
dsvm/7064ee5/logs/old/screen-n-cpu.txt.gz?level=TRACE#_2014-09-07_02_27_10_408

Libvirt stacktrace in n-cpu:

 Traceback (most recent call last):
   File "/opt/stack/old/nova/nova/compute/manager.py", line 1329, in 
_build_instance
 set_access_ip=set_access_ip)
   File "/opt/stack/old/nova/nova/compute/manager.py", line 393, in 
decorated_function
 return function(self, context, *args, **kwargs)
   File "/opt/stack/old/nova/nova/compute/manager.py", line 1741, in _spawn
 LOG.exception(_('Instance failed to spawn'), instance=instance)
   File "/opt/stack/old/nova/nova/openstack/common/excutils.py", line 68, in 
__exit__
 six.reraise(self.type_, self.value, self.tb)
   File "/opt/stack/old/nova/nova/compute/manager.py", line 1738, in _spawn
 block_device_info)
   File "/opt/stack/old/nova/nova/virt/libvirt/driver.py", line 2286, in spawn
 block_device_info)
   File "/opt/stack/old/nova/nova/virt/libvirt/driver.py", line 3686, in 
_create_domain_and_network
 power_on=power_on)
   File "/opt/stack/old/nova/nova/virt/libvirt/driver.py", line 3588, in 
_create_domain
 domain.XMLDesc(0))
   File "/opt/stack/old/nova/nova/openstack/common/excutils.py", line 68, in 
__exit__
 six.reraise(self.type_, self.value, self.tb)
   File "/opt/stack/old/nova/nova/virt/libvirt/driver.py", line 3583, in 
_create_domain
 domain.createWithFlags(launch_flags)
   File "/usr/lib/python2.7/dist-packages/eventlet/tpool.py", line 179, in doit
 result = proxy_call(self._autowrap, f, *args, **kwargs)
   File "/usr/lib/python2.7/dist-packages/eventlet/tpool.py", line 139, in 
proxy_call
 rv = execute(f,*args,**kwargs)
   File "/usr/lib/python2.7/dist-packages/eventlet/tpool.py", line 77, in 
tworker
 rv = meth(*args,**kwargs)
   File "/usr/lib/python2.7/dist-packages/libvirt.py", line 896, in 
createWithFlags
 if ret == -1: raise libvirtError ('virDomainCreateWithFlags() failed', 
dom=self)
 libvirtError: internal error: process exited while connecting to monitor: 
Cannot set up guest memory 'pc.ram': Cannot allocate memory

query: message:"Cannot set up guest memory 'pc.ram': Cannot allocate
memory" AND tags:"screen-n-cpu.txt"  AND  tags:"multiline"

** Affects: ceilometer
 Importance: Undecided
 Status: New

** Affects: nova
 Importance: Undecided
 Status: Confirmed

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

Title:
  libvirtError: internal error: process exited while connecting to
  monitor: Cannot set up guest memory 'pc.ram': Cannot allocate memory

Status in OpenStack Telemetry (Ceilometer):
  New
Status in OpenStack Compute (Nova):
  Confirmed

Bug description:
  http://logs.openstack.org/41/116741/5/gate/gate-grenade-
  dsvm/7064ee5/logs/old/screen-n-cpu.txt.gz?level=TRACE#_2014-09-07_02_27_10_408

  Libvirt stacktrace in n-cpu:

   Traceback (most recent call last):
     File "/opt/stack/old/nova/nova/compute/manager.py", line 1329, in 
_build_instance
   set_access_ip=set_access_ip)
     File "/opt/stack/old/nova/nova/compute/manager.py", line 393, in 
decorated_function
   return function(self, context, *args, **kwargs)
     File "/opt/stack/old/nova/nova/compute/manager.py", line 1741, in _spawn
   LOG.exception(_('Instance failed to spawn'), instance=instance)
     File "/opt/stack/old/nova/nova/openstack/common/excutils.py", line 68, in 
__exit__
   six.reraise(self.type_, self.value, self.tb)
     File "/opt/stack/old/nova/nova/compute/manager.py", line 1738, in _spawn
   block_device_info)
     File "/opt/stack/old/nova/nova/virt/libvirt/driver.py", line 2286, in spawn
   block_device_info)
     File "/opt/stack/old/nova/nova/virt/libvirt/driver.py", line 3686, in 
_create_domain_and_network
   power_on=power_on)
     File "/opt/stack/old/nova/nova/virt/libvirt/driver.py", line 3588, in 
_create_domain
   domain.XMLDesc(0))
     File "/opt/stack/old/nova/nova/openstack/common/excutils.py", line 68, in 
__exit__
   six.reraise(self.type_, self.value, self.tb)
     File "/opt/stack/old/nova/nova/virt/libvirt/driver.py", line 3583, in 
_create_domain
   domain.createWithFlags(launch_flags)
     File "/usr/lib/python2.7/dist-packages/eventlet/tpool.py", line 179, in 
doit
   result = proxy_call(self._autowrap, f, *args, **kwargs)
     File "/usr/lib/python2.7/dist-packages/eventlet/tpool.py", line 139, in 
proxy_call
   rv = execute(f,*args,**kwargs)
     File "/usr/lib/python2.7/dist-packages/eventlet/tpool.py", line 77, in 
tworker
   rv = meth(*args,**kwargs)
     File "/usr/lib/python2.7/dist-packages/libvirt.py", line 896, in 
createWithFlags
   if ret == -1: raise libvirtError ('virDomainCreateWithFlags() failed', 
dom=self)
   libvirtError: internal error: process exited

[Yahoo-eng-team] [Bug 1366921] [NEW] NSX: create_port should return empty list instead of null for allowed-address-pair

Public bug reported:


ft133.5: 
tempest.api.network.test_ports.PortsTestJSON.test_show_port[gate,smoke]_StringException:
 pythonlogging:'': {{{2014-09-07 18:53:43,165 17979 INFO 
[tempest.common.rest_client] Request (PortsTestJSON:test_show_port): 200 GET 
http://localhost:9696/v2.0/ports/2827a27a-dee1-4013-b90f-cf2aeeae5f4f 0.030s}}}

Traceback (most recent call last):
  File "tempest/api/network/test_ports.py", line 81, in test_show_port
(port, excluded_keys=['extra_dhcp_opts']))
  File 
"/opt/stack/tempest/.tox/smoke-serial/local/lib/python2.7/site-packages/testtools/testcase.py",
 line 433, in assertThat
raise mismatch_error
MismatchError: Only in actual:
  {'binding:vnic_type': normal}
Differences:
  allowed_address_pairs: expected [], actual None

Traceback (most recent call last):
_StringException: Empty attachments:
  stderr
  stdout

pythonlogging:'': {{{2014-09-07 18:53:43,165 17979 INFO
[tempest.common.rest_client] Request (PortsTestJSON:test_show_port): 200
GET http://localhost:9696/v2.0/ports/2827a27a-dee1-4013-b90f-
cf2aeeae5f4f 0.030s}}}

Traceback (most recent call last):
  File "tempest/api/network/test_ports.py", line 81, in test_show_port
(port, excluded_keys=['extra_dhcp_opts']))
  File 
"/opt/stack/tempest/.tox/smoke-serial/local/lib/python2.7/site-packages/testtools/testcase.py",
 line 433, in assertThat
raise mismatch_error
MismatchError: Only in actual:
  {'binding:vnic_type': normal}
Differences:
  allowed_address_pairs: expected [], actual None

Traceback (most recent call last):
_StringException: Empty attachments:
  stderr
  stdout

pythonlogging:'': {{{2014-09-07 18:53:43,165 17979 INFO
[tempest.common.rest_client] Request (PortsTestJSON:test_show_port): 200
GET http://localhost:9696/v2.0/ports/2827a27a-dee1-4013-b90f-
cf2aeeae5f4f 0.030s}}}

Traceback (most recent call last):
  File "tempest/api/network/test_ports.py", line 81, in test_show_port
(port, excluded_keys=['extra_dhcp_opts']))
  File 
"/opt/stack/tempest/.tox/smoke-serial/local/lib/python2.7/site-packages/testtools/testcase.py",
 line 433, in assertThat
raise mismatch_error
MismatchError: Only in actual:
  {'binding:vnic_type': normal}
Differences:
  allowed_address_pairs: expected [], actual None

** Affects: neutron
 Importance: High
 Assignee: Aaron Rosen (arosen)
 Status: In Progress


** Tags: vmware

** Changed in: neutron
 Assignee: (unassigned) => Aaron Rosen (arosen)

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

** Tags added: vmware

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

Title:
  NSX: create_port should return empty list instead of null for allowed-
  address-pair

Status in OpenStack Neutron (virtual network service):
  In Progress

Bug description:
  
  ft133.5: 
tempest.api.network.test_ports.PortsTestJSON.test_show_port[gate,smoke]_StringException:
 pythonlogging:'': {{{2014-09-07 18:53:43,165 17979 INFO 
[tempest.common.rest_client] Request (PortsTestJSON:test_show_port): 200 GET 
http://localhost:9696/v2.0/ports/2827a27a-dee1-4013-b90f-cf2aeeae5f4f 0.030s}}}

  Traceback (most recent call last):
File "tempest/api/network/test_ports.py", line 81, in test_show_port
  (port, excluded_keys=['extra_dhcp_opts']))
File 
"/opt/stack/tempest/.tox/smoke-serial/local/lib/python2.7/site-packages/testtools/testcase.py",
 line 433, in assertThat
  raise mismatch_error
  MismatchError: Only in actual:
{'binding:vnic_type': normal}
  Differences:
allowed_address_pairs: expected [], actual None

  Traceback (most recent call last):
  _StringException: Empty attachments:
stderr
stdout

  pythonlogging:'': {{{2014-09-07 18:53:43,165 17979 INFO
  [tempest.common.rest_client] Request (PortsTestJSON:test_show_port):
  200 GET http://localhost:9696/v2.0/ports/2827a27a-dee1-4013-b90f-
  cf2aeeae5f4f 0.030s}}}

  Traceback (most recent call last):
File "tempest/api/network/test_ports.py", line 81, in test_show_port
  (port, excluded_keys=['extra_dhcp_opts']))
File 
"/opt/stack/tempest/.tox/smoke-serial/local/lib/python2.7/site-packages/testtools/testcase.py",
 line 433, in assertThat
  raise mismatch_error
  MismatchError: Only in actual:
{'binding:vnic_type': normal}
  Differences:
allowed_address_pairs: expected [], actual None

  Traceback (most recent call last):
  _StringException: Empty attachments:
stderr
stdout

  pythonlogging:'': {{{2014-09-07 18:53:43,165 17979 INFO
  [tempest.common.rest_client] Request (PortsTestJSON:test_show_port):
  200 GET http://localhost:9696/v2.0/ports/2827a27a-dee1-4013-b90f-
  cf2aeeae5f4f 0.030s}}}

  Traceback (most recent call last):
File "tempest/api/network/test_ports.py", line 81, in test_show_port
  (port, excluded_keys=['extra_dhcp_opts']))
File 
"/opt/stack/tempest/.tox/smoke-serial/local/lib/python

[Yahoo-eng-team] [Bug 1366166] Re: Private flavor update with horizon will cause access issue of existed instances

2014-09-08 Thread Gary W. Smith

Closing per comment 2

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

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

Title:
  Private flavor update with horizon will cause access issue of existed
  instances

Status in OpenStack Dashboard (Horizon):
  Invalid

Bug description:
  How to reproduce

  1. create a private flavor "private-flavor"
  2. add a tenant access to "private-flavor"
  3. use regular user to create instance "XXX" with "private-flavor"
  4. add/remove tenant access to the "private-flavor" via horizon
  5. nova show XXX, will be end with error message say do not have access to 
the flavor

  Root cause,

  add/remove tenant access to the "private-flavor" via horizon. will do
  delete old one which will also delete the access to the old flavor,
  create new one with the same configuration, and add accesses back to
  the new flavor.

  The version before H3, horizon will pass flavor uuid to backend then
  will create new flavor with the same uuid, that's why it didn't cause
  problem, but it also cause another bug
  https://bugs.launchpad.net/horizon/+bug/1276371

  
  one quick solution is mark  deleted flavor as public in nova

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1366166/+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 1366917] [NEW] neutron should not use neutronclients utils methods

Public bug reported:

2014-09-07 19:17:58.331 | Traceback (most recent call last):
2014-09-07 19:17:58.331 |   File "/usr/local/bin/neutron-debug", line 6, in 
2014-09-07 19:17:58.332 | from neutron.debug.shell import main
2014-09-07 19:17:58.332 |   File 
"/opt/stack/new/neutron/neutron/debug/shell.py", line 29, in 
2014-09-07 19:17:58.332 | 'probe-create': utils.import_class(
2014-09-07 19:17:58.332 | AttributeError: 'module' object has no attribute 
'import_class'
2014-09-07 19:17:58.375 | + exit_trap
2014-09-07 19:17:58.375 | + local r=1

** Affects: neutron
 Importance: Undecided
 Assignee: Aaron Rosen (arosen)
 Status: In Progress

** Changed in: neutron
 Assignee: (unassigned) => Aaron Rosen (arosen)

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

Title:
  neutron should not use neutronclients utils methods

Status in OpenStack Neutron (virtual network service):
  In Progress

Bug description:
  2014-09-07 19:17:58.331 | Traceback (most recent call last):
  2014-09-07 19:17:58.331 |   File "/usr/local/bin/neutron-debug", line 6, in 
  2014-09-07 19:17:58.332 | from neutron.debug.shell import main
  2014-09-07 19:17:58.332 |   File 
"/opt/stack/new/neutron/neutron/debug/shell.py", line 29, in 
  2014-09-07 19:17:58.332 | 'probe-create': utils.import_class(
  2014-09-07 19:17:58.332 | AttributeError: 'module' object has no attribute 
'import_class'
  2014-09-07 19:17:58.375 | + exit_trap
  2014-09-07 19:17:58.375 | + local r=1

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1366917/+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 1366911] [NEW] Nova does not ensure a valid token is available if snapshot process exceeds token lifetime

2014-09-08 Thread Micheal Jones

Public bug reported:

Recently we encountered the following issue due to the change in
Icehouse for the default lifetime of a token before it expires. It's now
1 hour, while previously it was 8.

If a snapshot process takes longer than an hour, when it goes to the
next phase it will fail with a 401 Unauthorized error because it has an
invalid token.

In our specific example the following would take place:

1. User would set a snapshot to begin and a token would be associated with this 
request.
2. Snapshot would be created, compression time would take about 55 minutes. 
Enough to just push the snapshotting of this instance over the 60 minute mark.
3. Upon Image Upload ("Uploading image data for image" in the logs) Nova would 
then return a 401 Unauthorized error stating "This server could not verify that 
you are authorized to access the document you requested. Either you supplied 
the wrong credentials (e.g., bad password), or your browser does not understand 
how to supply the credentials required."

Icehouse 2014.1.2, KVM as the hypervisor.

The workaround is to specify a longer token timeout - however limits the
ability to set short token expirations.

A possible solution may be to get a new/refresh the token if the time
has exceeded the timeout.

** Affects: nova
 Importance: Undecided
 Status: New

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

Title:
  Nova does not ensure a valid token is available if snapshot process
  exceeds token lifetime

Status in OpenStack Compute (Nova):
  New

Bug description:
  Recently we encountered the following issue due to the change in
  Icehouse for the default lifetime of a token before it expires. It's
  now 1 hour, while previously it was 8.

  If a snapshot process takes longer than an hour, when it goes to the
  next phase it will fail with a 401 Unauthorized error because it has
  an invalid token.

  In our specific example the following would take place:

  1. User would set a snapshot to begin and a token would be associated with 
this request.
  2. Snapshot would be created, compression time would take about 55 minutes. 
Enough to just push the snapshotting of this instance over the 60 minute mark.
  3. Upon Image Upload ("Uploading image data for image" in the logs) Nova 
would then return a 401 Unauthorized error stating "This server could not 
verify that you are authorized to access the document you requested. Either you 
supplied the wrong credentials (e.g., bad password), or your browser does not 
understand how to supply the credentials required."

  Icehouse 2014.1.2, KVM as the hypervisor.

  The workaround is to specify a longer token timeout - however limits
  the ability to set short token expirations.

  A possible solution may be to get a new/refresh the token if the time
  has exceeded the timeout.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1366911/+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 1366909] [NEW] disk image create creates image size of atleast 1G

2014-09-08 Thread jsb

Public bug reported:

disk image create creates a qcow2 image with virtual size of atleast 1G. If 
DISK-IMAGE-SIZE is used in decimals,then, truncate command errors out as 
invalid number. This forces the image to be atleast 1G in size. Could this made 
in Mega bytes so that image less than 1 G can be created.
Thanks

** Affects: nova
 Importance: Undecided
 Status: New

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

Title:
  disk image create creates image size of atleast 1G

Status in OpenStack Compute (Nova):
  New

Bug description:
  disk image create creates a qcow2 image with virtual size of atleast 1G. If 
DISK-IMAGE-SIZE is used in decimals,then, truncate command errors out as 
invalid number. This forces the image to be atleast 1G in size. Could this made 
in Mega bytes so that image less than 1 G can be created.
  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1366909/+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 1366649] Re: Typo in keystone/common/base64utils.py

2014-09-08 Thread Dolph Mathews

This isn't a useful bug report, especially given that there's no useful
information here about the actual typo you're referring to. Happy to see
typos fixed without a bug report.

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

** Changed in: keystone
   Status: In Progress => Invalid

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

Title:
  Typo in keystone/common/base64utils.py

Status in OpenStack Identity (Keystone):
  Invalid

Bug description:
  Typo in keystone/common/base64utils.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1366649/+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 1366905] [NEW] Migration from havana to icehouse takes forever if large subset of data is present

2014-09-08 Thread David Hill

Public bug reported:

Hi guys,

I think the upgrade documentation from Havana to Icehouse should be
updated so keystone-manage token_flush is used before anything else.
If keystone token_flush is present in Havana, it should definitely be
ran before doing anything else too.

Still runing after 30 minutes:

mysql> show processlist;
++--+---+--+-+--+---++
| Id | User | Host  | db   | Command | Time | State | 
Info   |
++--+---+--+-+--+---++
| 547285 | root | localhost | keystone | Query   |0 | NULL  | 
show processlist   |
| 547349 | root | localhost | keystone | Query   | 1899 | copy to tmp table | 
ALTER TABLE keystone.token CONVERT TO CHARACTER SET 'utf8' |
++--+---+--+-+--+---++
2 rows in set (0.00 sec)


Dave

** Affects: keystone
 Importance: Undecided
 Status: New


** Tags: documentation havana icehouse keystone migration

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

Title:
  Migration from havana to icehouse takes forever if large subset of
  data is present

Status in OpenStack Identity (Keystone):
  New

Bug description:
  Hi guys,

  I think the upgrade documentation from Havana to Icehouse should
  be updated so keystone-manage token_flush is used before anything
  else.   If keystone token_flush is present in Havana, it should
  definitely be ran before doing anything else too.

  Still runing after 30 minutes:

  mysql> show processlist;
  
++--+---+--+-+--+---++
  | Id | User | Host  | db   | Command | Time | State | 
Info   |
  
++--+---+--+-+--+---++
  | 547285 | root | localhost | keystone | Query   |0 | NULL  | 
show processlist   |
  | 547349 | root | localhost | keystone | Query   | 1899 | copy to tmp table | 
ALTER TABLE keystone.token CONVERT TO CHARACTER SET 'utf8' |
  
++--+---+--+-+--+---++
  2 rows in set (0.00 sec)

  
  Dave

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1366905/+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 1366890] [NEW] Setting admin_state_up=False on a HA port causes split brain in HA routers

2014-09-08 Thread Assaf Muller

Public bug reported:

1) Create a HA router on a setup with two L3 agents
2) Find out who the master is
3) Find out what is the HA port used by the master instance of the router
4) Set it to admin state down

The master instance won't be able to send VRRP messages, but since the
tap device in the router namespace is still up, keepalive doesn't
transition to backup or fault. It remains in the master state. The
backup will stop receiving VRRP messages and will transition to master
as well.

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: l3-ha

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

Title:
  Setting admin_state_up=False on a HA port causes split brain in HA
  routers

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  1) Create a HA router on a setup with two L3 agents
  2) Find out who the master is
  3) Find out what is the HA port used by the master instance of the router
  4) Set it to admin state down

  The master instance won't be able to send VRRP messages, but since the
  tap device in the router namespace is still up, keepalive doesn't
  transition to backup or fault. It remains in the master state. The
  backup will stop receiving VRRP messages and will transition to master
  as well.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1366890/+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 1366891] [NEW] warning to console in container on failed resize

2014-09-08 Thread Scott Moser

Public bug reported:

inside a container, a device may exist, but even as root not be able to write 
to it.
currently that results in warning to console.

$ lsb_release -sc
trusty

$ awk '$5 == "/" { print $0 }' /proc/self/mountinfo 
79 61 253:1 /var/lib/lxc/t1/rootfs / rw,relatime - ext4 
/dev/disk/by-label/cloudimg-rootfs rw,data=ordered


$ ls -l /dev/disk/by-label/cloudimg-rootfs
lrwxrwxrwx 1 root root 11 Sep  4 12:49 /dev/disk/by-label/cloudimg-rootfs -> 
../../loop0
$ ls -l /dev/loop0
brw-rw 1 root disk 7, 0 Sep  4 12:49 /dev/loop0

$ sudo sh -c 'echo hi >/dev/loop0'
sh: 1: cannot create /dev/loop0: Operation not permitted
# outside this would give I/O error.

$ sudo python -c 'import os; print(os.access("/dev/loop0", os.W_OK))'
False

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: cloud-init 0.7.5-0ubuntu1.1
ProcVersionSignature: User Name 3.13.0-35.62-generic 3.13.11.6
Uname: Linux 3.13.0-35-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.3
Architecture: amd64
Date: Mon Sep  8 16:24:56 2014
Ec2AMI: ami-0064
Ec2AMIManifest: FIXME
Ec2AvailabilityZone: nova
Ec2InstanceType: m1.medium
Ec2Kernel: aki-0002
Ec2Ramdisk: ari-0002
PackageArchitecture: all
ProcEnviron:
 TERM=screen
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: cloud-init
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.init.cloud.init.local.conf: 2014-09-08T14:38:58.888631

** Affects: cloud-init
 Importance: Medium
 Status: In Progress

** Affects: cloud-init (Ubuntu)
 Importance: Medium
 Status: Confirmed


** Tags: amd64 apport-bug ec2-images trusty

** Also affects: cloud-init
   Importance: Undecided
   Status: New

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

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

** Changed in: cloud-init
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu)
   Status: New => Confirmed

** Changed in: cloud-init
   Status: Confirmed => In Progress

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

Title:
  warning to console in container on failed resize

Status in Init scripts for use on cloud images:
  In Progress
Status in “cloud-init” package in Ubuntu:
  Confirmed

Bug description:
  inside a container, a device may exist, but even as root not be able to write 
to it.
  currently that results in warning to console.

  $ lsb_release -sc
  trusty

  $ awk '$5 == "/" { print $0 }' /proc/self/mountinfo 
  79 61 253:1 /var/lib/lxc/t1/rootfs / rw,relatime - ext4 
/dev/disk/by-label/cloudimg-rootfs rw,data=ordered

  
  $ ls -l /dev/disk/by-label/cloudimg-rootfs
  lrwxrwxrwx 1 root root 11 Sep  4 12:49 /dev/disk/by-label/cloudimg-rootfs -> 
../../loop0
  $ ls -l /dev/loop0
  brw-rw 1 root disk 7, 0 Sep  4 12:49 /dev/loop0

  $ sudo sh -c 'echo hi >/dev/loop0'
  sh: 1: cannot create /dev/loop0: Operation not permitted
  # outside this would give I/O error.

  $ sudo python -c 'import os; print(os.access("/dev/loop0", os.W_OK))'
  False

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: cloud-init 0.7.5-0ubuntu1.1
  ProcVersionSignature: User Name 3.13.0-35.62-generic 3.13.11.6
  Uname: Linux 3.13.0-35-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3.3
  Architecture: amd64
  Date: Mon Sep  8 16:24:56 2014
  Ec2AMI: ami-0064
  Ec2AMIManifest: FIXME
  Ec2AvailabilityZone: nova
  Ec2InstanceType: m1.medium
  Ec2Kernel: aki-0002
  Ec2Ramdisk: ari-0002
  PackageArchitecture: all
  ProcEnviron:
   TERM=screen
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: cloud-init
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.init.cloud.init.local.conf: 2014-09-08T14:38:58.888631

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1366891/+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 1359995] Fix merged to devstack (master)

2014-09-08 Thread OpenStack Infra

Reviewed:  https://review.openstack.org/116133
Committed: 
https://git.openstack.org/cgit/openstack-dev/devstack/commit/?id=2a6ce7197e5da9faba2faff2a18c04ece957
Submitter: Jenkins
Branch:master

commit 2a6ce7197e5da9faba2faff2a18c04ece957
Author: Brant Knudson 
Date:   Thu Aug 21 18:23:12 2014 -0500

Change httpd Keystone access log to keystone_access.log

Keystone's access log was going to httpd/access.log, which is the
common place for all access logging. This made it difficult to see
Keystone accesses apart from other access. Keystone's access log
will now be keystone_access.log

This makes the Keystone configuration similar to Horizon which uses
horizon_access.log.

Change-Id: I6e5ac121302b3d138758e6c49dffa9f05ad2fb85
Partial-Bug: #1359995


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

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

Title:
  Tempest failed to delete user

Status in devstack - openstack dev environments:
  Fix Released
Status in OpenStack Identity (Keystone):
  Incomplete
Status in Tempest:
  New

Bug description:
  
  check-tempest-dsvm-full failed on a keystone change. Here's the main log: 
http://logs.openstack.org/73/111573/4/check/check-tempest-dsvm-full/c5ce3bd/console.html

  The traceback shows:

  File "tempest/api/volume/test_volumes_list.py", line 80, in tearDownClass
  File "tempest/services/identity/json/identity_client.py", line 189, in 
delete_user
  Unauthorized: Unauthorized
  Details: {"error": {"message": "The request you have made requires 
authentication. (Disable debug mode to suppress these details.)", "code": 401, 
"title": "Unauthorized"}}

  So it's trying to delete the user and it gets unauthorized. Maybe the
  token was expired or marked invalid for some reason.

  There's something wrong here, but the keystone logs are useless for
  debugging now that it's running in Apache httpd. The logs don't have
  the request or result line, so you can't find where the request was
  being made.

  Also, Tempest should be able to handle the token being invalidated. It
  should just get a new token and try with that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/devstack/+bug/1359995/+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 1240355] Re: Broken pipe error when copying image from glance to vSphere

from Jaroslav's last comment it seems like an issue with glance image-
create with --file and not Nova per se

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

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

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

Title:
  Broken pipe error when copying image from glance to vSphere

Status in OpenStack Image Registry and Delivery Service (Glance):
  New
Status in OpenStack Compute (Nova):
  Incomplete

Bug description:
  Using the VMwareVCDriver on the latest nova (6affe67067) from master,
  launching an image for the first time is failing when copying image
  from Glance to vSphere. The error that shows in the nova log is:

  Traceback (most recent call last):
File "/opt/stack/nova/nova/virt/vmwareapi/io_util.py", line 176, in _inner
  self.output.write(data)
File "/opt/stack/nova/nova/virt/vmwareapi/read_write_util.py", line 143, in 
write
  self.file_handle.send(data)
File "/usr/lib/python2.7/httplib.py", line 790, in send
  self.sock.sendall(data)
File "/usr/local/lib/python2.7/dist-packages/eventlet/green/ssl.py", line 
131, in sendall
  v = self.send(data[count:])
File "/usr/local/lib/python2.7/dist-packages/eventlet/green/ssl.py", line 
107, in send
  super(GreenSSLSocket, self).send, data, flags)
File "/usr/local/lib/python2.7/dist-packages/eventlet/green/ssl.py", line 
77, in 
  return func(*a, **kw)
File "/usr/lib/python2.7/ssl.py", line 198, in send
  v = self._sslobj.write(data)
  error: [Errno 32] Broken pipe

  To reproduce, launch an instance using an image that has not yet been
  uploaded to vSphere. I have attached the full log here:
  http://paste.openstack.org/show/48536/

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1240355/+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 1262057] Re: XML middleware will try to convert everything even if it's not json

2014-09-08 Thread David Stanek

The XML middleware has been marked as deprecated so I don't see a lot of
work happening here.

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

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

Title:
  XML middleware will try to convert everything even if it's not json

Status in OpenStack Identity (Keystone):
  Won't Fix

Bug description:
  There are certain routes like /v2.0/certificates/ca that return PEM
  files that do not return the standard choice of JSON or XML data. If
  you request these routes with XML in the Accept field (like if you hit
  it with a browser) then the XML middleware will kick in and assume
  that, like other requests, it needs to load it as json then convert it
  to xml.

  This is obviously wrong. We should only be doing XML processing if we
  understand the content we are trying to convert, and it is better to
  return something that is not on the Accept list than return an error
  (in JSON no less).

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1262057/+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 1233368] Re: Unauthorized command: kill -9

2014-09-08 Thread Sam Betts

Fixed in master by https://review.openstack.org/56785

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

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

Title:
  Unauthorized command: kill -9

Status in OpenStack Neutron (virtual network service):
  Fix Released

Bug description:
   Stderr: '/usr/local/bin/neutron-rootwrap: Unauthorized command: kill
  -9 30601 (no filter matched)\n'

  
  2013-09-30 17:56:22.682 2684 ERROR neutron.agent.dhcp_agent [-] Unable to 
disable dhcp.
  2013-09-30 17:56:22.682 2684 TRACE neutron.agent.dhcp_agent Traceback (most 
recent call last):
  2013-09-30 17:56:22.682 2684 TRACE neutron.agent.dhcp_agent   File 
"/opt/stack/new/neutron/neutron/agent/dhcp_agent.py", line 126, in call_driver
  2013-09-30 17:56:22.682 2684 TRACE neutron.agent.dhcp_agent 
getattr(driver, action)(**action_kwargs)
  2013-09-30 17:56:22.682 2684 TRACE neutron.agent.dhcp_agent   File 
"/opt/stack/new/neutron/neutron/agent/linux/dhcp.py", line 180, in disable
  2013-09-30 17:56:22.682 2684 TRACE neutron.agent.dhcp_agent 
utils.execute(cmd, self.root_helper)
  2013-09-30 17:56:22.682 2684 TRACE neutron.agent.dhcp_agent   File 
"/opt/stack/new/neutron/neutron/agent/linux/utils.py", line 61, in execute
  2013-09-30 17:56:22.682 2684 TRACE neutron.agent.dhcp_agent raise 
RuntimeError(m)
  2013-09-30 17:56:22.682 2684 TRACE neutron.agent.dhcp_agent RuntimeError: 
  2013-09-30 17:56:22.682 2684 TRACE neutron.agent.dhcp_agent Command: ['sudo', 
'/usr/local/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'kill', '-9', 
'30601']
  2013-09-30 17:56:22.682 2684 TRACE neutron.agent.dhcp_agent Exit code: 99
  2013-09-30 17:56:22.682 2684 TRACE neutron.agent.dhcp_agent Stdout: ''
  2013-09-30 17:56:22.682 2684 TRACE neutron.agent.dhcp_agent Stderr: 
'/usr/local/bin/neutron-rootwrap: Unauthorized command: kill -9 30601 (no 
filter matched)\n'
  2013-09-30 17:56:22.682 2684 TRACE neutron.agent.dhcp_agent 

  http://logs.openstack.org/03/47503/16/check/check-tempest-devstack-vm-
  neutron/0b35b85/logs/screen-q-dhcp.txt.gz?level=TRACE

  logstash query: "Unauthorized command: kill -9" shows this has
  happened about 100 times in past 24 hours and sometimes happens on
  'successful' tempest runs.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1233368/+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 1366859] [NEW] extra_spec requirement 'amd64' does not match 'x86_64'

2014-09-08 Thread Dan Prince

Public bug reported:

Using the latest Nova Ironic compute drivers (either from Ironic or
Nova) I'm hitting scheduling ERRORS:

Sep 08 15:26:45 localhost nova-scheduler[29761]: 2014-09-08 15:26:45.620
29761 DEBUG nova.scheduler.filters.compute_capabilities_filter [req-
9e34510e-268c-40de-8433-d7b41017b54e None] extra_spec requirement
'amd64' does not match 'x86_64' _satisfies_extra_specs
/opt/stack/venvs/nova/lib/python2.7/site-
packages/nova/scheduler/filters/compute_capabilities_filter.py:70

I've gone ahead and patched in https://review.openstack.org/#/c/117555/.

The issue seems to be that ComputeCapabilitiesFilter does not itself
canonicalize instance_types when comparing them which will breaks
existing TripleO baremetal clouds using x86_64 (amd64).

** Affects: nova
 Importance: Critical
 Status: New

** Changed in: nova
   Importance: Undecided => Critical

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

Title:
  extra_spec requirement 'amd64' does not match 'x86_64'

Status in OpenStack Compute (Nova):
  New

Bug description:
  Using the latest Nova Ironic compute drivers (either from Ironic or
  Nova) I'm hitting scheduling ERRORS:

  Sep 08 15:26:45 localhost nova-scheduler[29761]: 2014-09-08
  15:26:45.620 29761 DEBUG
  nova.scheduler.filters.compute_capabilities_filter [req-9e34510e-268c-
  40de-8433-d7b41017b54e None] extra_spec requirement 'amd64' does not
  match 'x86_64' _satisfies_extra_specs
  /opt/stack/venvs/nova/lib/python2.7/site-
  packages/nova/scheduler/filters/compute_capabilities_filter.py:70

  I've gone ahead and patched in
  https://review.openstack.org/#/c/117555/.

  The issue seems to be that ComputeCapabilitiesFilter does not itself
  canonicalize instance_types when comparing them which will breaks
  existing TripleO baremetal clouds using x86_64 (amd64).

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1366859/+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 1366861] [NEW] user unable to read flavor list without admin role

2014-09-08 Thread Bharath

Public bug reported:

Hi,

I have created 20 VMs from a snapshot, each user login is associated to
an individual project and this project is added to the custom flavor i
have created, the requirement was to ensure these users don't see each
other's VMs, after launching the image the instances were accessible on
the launch of 20th VM it started throwing error at Instance view as
below

Error: Unable to retrieve instance size information.

On drill down of the instance: Error: Unable to retrieve details for
instance "77521784-86a1-40e0-a083-ad0b560779dc

below are the traces i found in Apache2 log, nova-api log and finally
keystone where it said the user needs Admin access to read the flavor
which is unusual as the project to which the user is associated is
already included in the flavor access list, this was reproducible after
creating 20th VM or later in different projects.

Apache Horizon error:
[Mon Sep 08 15:21:21.969164 2014] [:error] [pid 5945:tid 140202637772544] 
NotFound: The resource could not be found. (HTTP 404) (Request-ID: 
req-c10869e3-81ea-4f2a-b6c3-9026cceaf43e)


Nova-api:
2014-09-08 20:51:21.869 2643 INFO nova.osapi_compute.wsgi.server 
[req-a4cdad89-047e-4451-85ed-caff08efb5f7 3f1474d0b016486c869e488b048ef5bb 
ab48d34b800545019fae208a43d8c254] 172.31.100.103 "GET 
/v2/ab48d34b800545019fae208a43d8c254/flavors/detail HTTP/1.1" status: 200 len: 
704 time: 0.0101700
2014-09-08 20:51:21.967 2643 INFO nova.api.openstack.wsgi 
[req-c10869e3-81ea-4f2a-b6c3-9026cceaf43e 3f1474d0b016486c869e488b048ef5bb 
ab48d34b800545019fae208a43d8c254] HTTP exception thrown: The resource could not 
be found.


Keystone error:
2014-09-08 20:41:45.346 46413 WARNING keystone.common.wsgi [-] You are not 
authorized to perform the requested action, admin_required.

** Affects: nova
 Importance: Undecided
 Status: New

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

Title:
  user unable to read flavor list without admin role

Status in OpenStack Compute (Nova):
  New

Bug description:
  Hi,

  I have created 20 VMs from a snapshot, each user login is associated
  to an individual project and this project is added to the custom
  flavor i have created, the requirement was to ensure these users don't
  see each other's VMs, after launching the image the instances were
  accessible on the launch of 20th VM it started throwing error at
  Instance view as below

  Error: Unable to retrieve instance size information.

  On drill down of the instance: Error: Unable to retrieve details for
  instance "77521784-86a1-40e0-a083-ad0b560779dc

  below are the traces i found in Apache2 log, nova-api log and finally
  keystone where it said the user needs Admin access to read the flavor
  which is unusual as the project to which the user is associated is
  already included in the flavor access list, this was reproducible
  after creating 20th VM or later in different projects.

  Apache Horizon error:
  [Mon Sep 08 15:21:21.969164 2014] [:error] [pid 5945:tid 140202637772544] 
NotFound: The resource could not be found. (HTTP 404) (Request-ID: 
req-c10869e3-81ea-4f2a-b6c3-9026cceaf43e)

  
  Nova-api:
  2014-09-08 20:51:21.869 2643 INFO nova.osapi_compute.wsgi.server 
[req-a4cdad89-047e-4451-85ed-caff08efb5f7 3f1474d0b016486c869e488b048ef5bb 
ab48d34b800545019fae208a43d8c254] 172.31.100.103 "GET 
/v2/ab48d34b800545019fae208a43d8c254/flavors/detail HTTP/1.1" status: 200 len: 
704 time: 0.0101700
  2014-09-08 20:51:21.967 2643 INFO nova.api.openstack.wsgi 
[req-c10869e3-81ea-4f2a-b6c3-9026cceaf43e 3f1474d0b016486c869e488b048ef5bb 
ab48d34b800545019fae208a43d8c254] HTTP exception thrown: The resource could not 
be found.

  
  Keystone error:
  2014-09-08 20:41:45.346 46413 WARNING keystone.common.wsgi [-] You are not 
authorized to perform the requested action, admin_required.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1366861/+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 1270516] Re: XmlBodyMiddleware logic causes an unnecessary JSON to dict conversion

2014-09-08 Thread David Stanek

The XML middleware has been marked as deprecated so I don't see a lot of
work happening here.

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

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

Title:
  XmlBodyMiddleware logic causes an unnecessary JSON to dict conversion

Status in OpenStack Identity (Keystone):
  Won't Fix

Bug description:
  The XmlBodyMiddleware converts request body from XML string to JSON
  string and passes it on to the JsonBodyMiddleware next in chain.

  Observe the following line in the XmlBodyMiddleware.process_request method:
   request.body = jsonutils.dumps(
   serializer.from_xml(request.body))

  serializer.from_xml already converts the body to a python dict, but it
  dumps it again as a JSON string to the request body.

  Now, observe the following lines in JsonBodyMiddleware .process_request 
method:
  # Abort early if we don't have any work to do
  params_json = request.body
  if not params_json:
  return
   ...
  params = {}
  for k, v in params_parsed.iteritems():
  if k in ('self', 'context'):
  continue
  if k.startswith('_'):
  continue
  params[k] = v
  ...
  request.environ[PARAMS_ENV] = params

  The JsonBodyMiddleware converts JSON string to dict and then stores
  the dict in request.environ (It does some additional filtering of the
  dict before storing, but that doesn't look like it is JSON specific)

  So, if the input request body has XML and the xml_body/json_body
  middlware are used in the paste pipeline, the effective conversion is:
  XML string => dict => JSON string => dict

  This may induce a performance penalty (however minor it is) due to the
  unnecessary JSON to dict conversion. The following is the required
  conversion: XML string => dict

  To achieve this, the following could be done:

  Refactor the following lines from JsonBodyMiddlware.process_request method 
and move it to a common module as a method:
  params = {}
  for k, v in params_parsed.iteritems():
  if k in ('self', 'context'):
  continue
  if k.startswith('_'):
  continue
  params[k] = v

  Then, call that method from XmlBodyMiddleware.process_request method
  passing the serialized xml dict. Store the filtered dict as
  request.environ[PARAMS_ENV]. Then, set the request.body to None.

  With this change, the JsonBodyMiddlware next in chain would not process the 
request due to the following initial check:
  # Abort early if we don't have any work to do
  params_json = request.body
  if not params_json:
  return

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1270516/+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 922751] Re: undocumented parameter --flagfile in nova-manage

We don't have --flagfile anywhere in the code or docs in nova trunk.

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

Title:
  undocumented parameter --flagfile in nova-manage

Status in OpenStack Compute (Nova):
  Invalid

Bug description:
  nova-manage --config-file /opt/stack/nova/bin/nova.conf is not working on my 
devstack environment (nova.common.cfg.ConfigFileParseError: Failed to parse 
bin/nova.conf: File contains no section headers.
  file: bin/nova.conf, line: 1)

  using the undocumented (not listed in the output of nova-manage
  --help) paramater --flagfile is working without problems. I can't find
  the definition of the parameter "--flagfile". Looks like it's
  hardcoded in nova/utils.py in the method default_flagfile (there is a
  arg.find('flagfile')).

  stack@devstack001:~$ nova-manage --flagfile /opt/stack/nova/bin/nova.conf db 
version
  74

  stack@devstack001:~$ nova-manage --help | grep flagfile
--dhcpbridge_flagfile=DHCPBRIDGE_FLAGFILE
  location of flagfile for dhcpbridge

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/922751/+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 1366842] [NEW] No way to set config-drive property when launching instance

2014-09-08 Thread Justin Pomeroy

Public bug reported:

The dashboard does not provide an option to enable/disable config drive
when launching an instance.  This is a problem for OpenStack deployments
that do not enable the metadata service.  For such deployments,
launching an instance from the dashboard will result in the image not
activating properly because config drive was not enabled.

The dashboard does provide options to set "Customization Script" (i.e.
user data), key pair, etc. which only work if config drive is enabled or
the metadata service is enabled.  Since a user cannot control whether or
not the metadata service is enabled, the user at least needs control of
config drive to ensure the options work.

** Affects: horizon
 Importance: Undecided
 Assignee: Justin Pomeroy (jpomero)
 Status: New

** Changed in: horizon
 Assignee: (unassigned) => Justin Pomeroy (jpomero)

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

Title:
  No way to set config-drive property when launching instance

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  The dashboard does not provide an option to enable/disable config
  drive when launching an instance.  This is a problem for OpenStack
  deployments that do not enable the metadata service.  For such
  deployments, launching an instance from the dashboard will result in
  the image not activating properly because config drive was not
  enabled.

  The dashboard does provide options to set "Customization Script" (i.e.
  user data), key pair, etc. which only work if config drive is enabled
  or the metadata service is enabled.  Since a user cannot control
  whether or not the metadata service is enabled, the user at least
  needs control of config drive to ensure the options work.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1366842/+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 1362651] Re: /0 subnet causes dhcp failures

2014-09-08 Thread Tristan Cacqueray

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

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

Title:
  /0 subnet causes dhcp failures

Status in OpenStack Neutron (virtual network service):
  In Progress
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Neutron allow for creating /0 subnet. This alone does not make a lot
  of sense.

  It also causes DHCP failures as the agent is not able to start the dnsmasq 
process.
  Trouble is that the DHCP agent goes into perennial fully resync mode.
  This might cause huge delays in setting up DHCP for other subnets, thus 
resulting in a potential DoS.

  So it might be better to prevent /0 subnets at all.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1362651/+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 1366832] [NEW] serial console, ports are not released

2014-09-08 Thread sahid

Public bug reported:

When booting an instance with serial console activated, port(s) are allocated 
but never released since the code responsible to freeing port(s) is called 
after the domain is undefined from libvirt.
Also since the domain is already undefined, when calling the method 
'_lookup_by_name' an exception "DomainnotFound" is raised which makes not 
possible to correctly finish the deleting process

** Affects: nova
 Importance: High
 Assignee: sahid (sahid-ferdjaoui)
 Status: New


** Tags: libvirt

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

Title:
  serial console, ports are not released

Status in OpenStack Compute (Nova):
  New

Bug description:
  When booting an instance with serial console activated, port(s) are allocated 
but never released since the code responsible to freeing port(s) is called 
after the domain is undefined from libvirt.
  Also since the domain is already undefined, when calling the method 
'_lookup_by_name' an exception "DomainnotFound" is raised which makes not 
possible to correctly finish the deleting process

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1366832/+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 1188073] Re: havana: nova - Remove broken config_drive image_href support

Looks like the doc is no long present, so there's nothing to fix. yay!

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

Title:
  havana: nova - Remove broken config_drive image_href support

Status in OpenStack Compute (Nova):
  Invalid

Bug description:
  If https://review.openstack.org/31314 it changes config drive support.
  
  image_href support has not been working since at least shortly before
  Folsom release.  This is a good indication that this functionality is not
  used.  As far as I can tell, the docs also do not match what was
  supported.  An image ID was required, but docs show examples with full
  hrefs.
  
  DocImpact
  
  http://docs.openstack.org/developer/nova/api_ext/ext_config_drive.html
  
  References to supporting image_hrefs should be removed.
  
  Docs also state that 'true' or 'True' (depending on if you use
  XML or JSON) or empty strings are returned for detail/show.  The
  nova code seems to actually return '1' or an empty string or None.
  
  This has been corrected in this patch to return 'True' (always
  capitalized) or '' if it is enabled/disabled respectively.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1188073/+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 1365499] Re: Error on df execution

2014-09-08 Thread Erno Kuvaja

I do not know which version of glance you are using, but this is fixed
in current master.

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

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

Title:
  Error on df execution

Status in OpenStack Image Registry and Delivery Service (Glance):
  Invalid

Bug description:
  Some time may happen that the df executed by _get_capacity_info in
  /usr/lib/python2.6/site-packages/glance/store/filesystem.py  has a
  multiple line output:

   Filesystem   1B-blocks  Used Available Use% Mounted on
  :/storesimple-L02
   1082256261120 209715200 1027071803392   1% 
/var/lib/glance/images1

  In this situation i recive this stacktrace:

  
  2014-09-04 14:52:49.263 14267 TRACE glance.api.v1.upload_utils Traceback 
(most recent call last):
  2014-09-04 14:52:49.263 14267 TRACE glance.api.v1.upload_utils   File 
"/usr/lib/python2.6/site-packages/glance/api/v1/upload_utils.py", line 99, in 
upload_data_to_store
  2014-09-04 14:52:49.263 14267 TRACE glance.api.v1.upload_utils store)
  2014-09-04 14:52:49.263 14267 TRACE glance.api.v1.upload_utils   File 
"/usr/lib/python2.6/site-packages/glance/store/__init__.py", line 380, in 
store_add_to_backend
  2014-09-04 14:52:49.263 14267 TRACE glance.api.v1.upload_utils (location, 
size, checksum, metadata) = store.add(image_id, data, size)
  2014-09-04 14:52:49.263 14267 TRACE glance.api.v1.upload_utils   File 
"/usr/lib/python2.6/site-packages/glance/store/filesystem.py", line 422, in add
  2014-09-04 14:52:49.263 14267 TRACE glance.api.v1.upload_utils datadir = 
self._find_best_datadir(image_size)
  2014-09-04 14:52:49.263 14267 TRACE glance.api.v1.upload_utils   File 
"/usr/lib/python2.6/site-packages/glance/store/filesystem.py", line 384, in 
_find_best_datadir
  2014-09-04 14:52:49.263 14267 TRACE glance.api.v1.upload_utils free_space 
= self._get_capacity_info(datadir)
  2014-09-04 14:52:49.263 14267 TRACE glance.api.v1.upload_utils   File 
"/usr/lib/python2.6/site-packages/glance/store/filesystem.py", line 361, in 
_get_capacity_info
  2014-09-04 14:52:49.263 14267 TRACE glance.api.v1.upload_utils 
total_available_space = int(df.split('\n')[1].split()[3])
  2014-09-04 14:52:49.263 14267 TRACE glance.api.v1.upload_utils IndexError: 
list index out of range
  2014-09-04 14:52:49.263 14267 TRACE glance.api.v1.upload_utils


  To solve this i sugest to exexute  a df with -P option

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1365499/+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 1320140] Re: Federation documentation is not clear about mapping.rules.local.user.name

2014-09-08 Thread Dolph Mathews

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

** This bug has been marked a duplicate of bug 1312221
   Add user objects to mapping rules examples in OS-FEDERATION docs

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

Title:
  Federation documentation is not clear about
  mapping.rules.local.user.name

Status in OpenStack Identity (Keystone):
  Triaged

Bug description:
  The documentation of the Federation API [1] brings a lot of examples
  where the local part of the rule does not have the user object with
  the name property, such as:

  {
  "user": {
  "name": "user name"
  }
  }

  However one cannot get a token with Federation if the mapping doesn't
  have such rule, because of the lines below: [2]

  mapped_properties = self._transform(identity_values)
  if mapped_properties.get('name') is None:
  raise exception.Unauthorized(_("Could not map user"))

  and the implementation of the method _transform, that is not lenient
  about the lack of the aforementioned object [3].

  
  [1] 
https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3-os-federation-ext.md
  [2] 
https://github.com/openstack/keystone/blob/01eea87dea766714015a62f5d24f07d2407f9612/keystone/contrib/federation/utils.py#L223
  [3] 
https://github.com/openstack/keystone/blob/01eea87dea766714015a62f5d24f07d2407f9612/keystone/contrib/federation/utils.py#L228

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1320140/+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 1366797] [NEW] Add UT assert to check subset of dict

2014-09-08 Thread Paul Michali

Public bug reported:

With the VPN unit tests, there are many occasions where there is a
desire to test if an actual dict contains keys and values specified in
some expected dict. The actual dict would be a superset, as there may be
keys (e.g. auth) that can be ignored.

Rather than make the change local to VPN code, this bug is suggesting to
add this as an assert into the base test class, so that everyone can use
it.

** Affects: neutron
 Importance: Undecided
 Assignee: Paul Michali (pcm)
 Status: In Progress

** Changed in: neutron
 Assignee: (unassigned) => Paul Michali (pcm)

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

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

Title:
  Add UT assert to check subset of dict

Status in OpenStack Neutron (virtual network service):
  In Progress

Bug description:
  With the VPN unit tests, there are many occasions where there is a
  desire to test if an actual dict contains keys and values specified in
  some expected dict. The actual dict would be a superset, as there may
  be keys (e.g. auth) that can be ignored.

  Rather than make the change local to VPN code, this bug is suggesting
  to add this as an assert into the base test class, so that everyone
  can use it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1366797/+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 757772] Re: Cloudpipe doesn't update the crl in userdata when a cert is revoked

looks like we don't have any "cloudpipe" code in Nova any more. marking
as invalid

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

Title:
  Cloudpipe doesn't update the crl in userdata when a cert is revoked

Status in OpenStack Compute (Nova):
  Invalid

Bug description:
  When a certificate is revoked (using nova-manage for example), a new
  payload with an updated crl is not generated.  This means that the
  cloudpipe vpn will need to be restarted to to pick up new information.

  The revoke should update the user data with a new payload.  That way
  the cloudpipe instance can periodically check for a new crl and update
  it.  This would allow revokation without needing to restart the vpn.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/757772/+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 925658] Re: RelaxNG schema is missing security_groups element for server create

Nova is in v2 API now and there are no RNG schemas for v2. So marking
this as won't fix.

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

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

Title:
  RelaxNG schema is missing security_groups element for server create

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

Bug description:
  The schema simply doesn't include security_groups:
  nova/api/openstack/compute/schemas/v1.1/server.rng

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/925658/+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 1366778] [NEW] Flavor names unnecessarily restrictive

2014-09-08 Thread Chris St. Pierre

Public bug reported:

Flavor names are restricted to "word" characters, period, dash, and
space, for no apparent reason. Flavor names should allow all printable
characters to obviate this unnecessary restriction. If nothing else,
this will make it easier to migrate from pre-Grizzly (I know, ancient
history) where the allowable flavor name regex was less restrictive.

** Affects: nova
 Importance: Undecided
 Status: New

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

Title:
  Flavor names unnecessarily restrictive

Status in OpenStack Compute (Nova):
  New

Bug description:
  Flavor names are restricted to "word" characters, period, dash, and
  space, for no apparent reason. Flavor names should allow all printable
  characters to obviate this unnecessary restriction. If nothing else,
  this will make it easier to migrate from pre-Grizzly (I know, ancient
  history) where the allowable flavor name regex was less restrictive.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1366778/+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 1255627] Re: images.test_list_image_filters.ListImageFiltersTest fails with timeout