[Yahoo-eng-team] [Bug 1439951] [NEW] glance.tests.unit.test_artifacts_plugin_loader unit test failed

2015-04-03 Thread John Haan 
Public bug reported:

The unit tests in glance.tests.unit.test_artifacts_plugin_loader was
failed.

glance.tests.unit.test_artifacts_plugin_loader.TestArtifactsLoader
test_config_validationFAIL
test_check_function   FAIL
test_basic_loader_funcOK  0.01
test_load FAIL

Below is the result of test_load() unit test.

==
FAIL: 
glance.tests.unit.test_artifacts_plugin_loader.TestArtifactsLoader.test_load
--
Traceback (most recent call last):
testtools.testresult.real._StringException: Traceback (most recent call last):
  File 
/home/jenkins/glance/glance/tests/unit/test_artifacts_plugin_loader.py, line 
67, in test_load
'MyArtifact=%s.v1.artifact:MyArtifact' % self.path]),
  File 
/home/jenkins/glance/glance/tests/unit/test_artifacts_plugin_loader.py, line 
49, in _setup_loader
pkg_resources.EntryPoint.parse(art) for art in artifacts]
  File /usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py, line 
2366, in parse
return cls(res['name'], res['module'], attrs, extras, dist)
  File /usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py, line 
2289, in __init__
raise ValueError(Invalid module name, module_name)
ValueError: ('Invalid module name', 
'.home.jenkins.glance.glance.tests.unit.test_artifacts_plugin_loader')

---


other results were same to the test_load() test.

The reason why is that I performs unit tests as jenkins user.
Therefore my working directory is /home/jenkins/glance/ .

when getting the path for _setup_loader()

It gets full path of file which means,

path = os.path.splitext(__file__)[0].replace('/', '.')

The full path is raised ValueError for module validation check.

** Affects: glance
 Importance: Undecided
 Assignee: John Haan (yongiman)
 Status: New

** Description changed:

  The unit tests in glance.tests.unit.test_artifacts_plugin_loader was
  failed.
  
  glance.tests.unit.test_artifacts_plugin_loader.TestArtifactsLoader
- test_config_validationFAIL
- test_check_function   FAIL
- test_basic_loader_funcOK  0.01
- test_load FAIL
+ test_config_validationFAIL
+ test_check_function   FAIL
+ test_basic_loader_funcOK  0.01
+ test_load FAIL
  
  Below is the result of test_load() unit test.
  
  ==
  FAIL: 
glance.tests.unit.test_artifacts_plugin_loader.TestArtifactsLoader.test_load
  --
  Traceback (most recent call last):
  testtools.testresult.real._StringException: Traceback (most recent call last):
-   File 
/home/jenkins/glance/glance/tests/unit/test_artifacts_plugin_loader.py, line 
67, in test_load
- 'MyArtifact=%s.v1.artifact:MyArtifact' % self.path]),
-   File 
/home/jenkins/glance/glance/tests/unit/test_artifacts_plugin_loader.py, line 
49, in _setup_loader
- pkg_resources.EntryPoint.parse(art) for art in artifacts]
-   File /usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py, 
line 2366, in parse
- return cls(res['name'], res['module'], attrs, extras, dist)
-   File /usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py, 
line 2289, in __init__
- raise ValueError(Invalid module name, module_name)
+   File 
/home/jenkins/glance/glance/tests/unit/test_artifacts_plugin_loader.py, line 
67, in test_load
+ 'MyArtifact=%s.v1.artifact:MyArtifact' % self.path]),
+   File 
/home/jenkins/glance/glance/tests/unit/test_artifacts_plugin_loader.py, line 
49, in _setup_loader
+ pkg_resources.EntryPoint.parse(art) for art in artifacts]
+   File /usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py, 
line 2366, in parse
+ return cls(res['name'], res['module'], attrs, extras, dist)
+   File /usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py, 
line 2289, in __init__
+ raise ValueError(Invalid module name, module_name)
  ValueError: ('Invalid module name', 
'.home.jenkins.glance.glance.tests.unit.test_artifacts_plugin_loader')
+ 
+ ---
+ 
  
  other results were same to the test_load() test.
  
  The reason why is that I performs unit tests as jenkins user.

[Yahoo-eng-team] [Bug 1436314] Re: Option to boot VM only from volume is not available

2015-04-03 Thread Nikola Đipanov 
It is enough to specify --boot-volume option, (see
https://wiki.openstack.org/wiki/BlockDeviceConfig for more details about
the block device mapping syntax).

Setting max_local_block_devices to 0 means that any request that
attempts to create a local disk will fail. This option is meant to limit
the number of local discs (so root local disc that is the result of
--image being used, and any other ephemeral and swap disks).

AFAIK Tempest by it's very nature will test both booting instances from
volumes and from images downloaded to hypervisor local storage, so it
makes very little sense to me to attempt to limit the environment
tempest runs against to allow only boot from volume and then expect to
be able to run tests that spawn instances from images.

 max_local_block_devices set to 0 does not mean that nova will
automatically convert --images to volumes and boot instances from
volumes - it just means that all request that attempt to create a local
disk will fail.

** Changed in: nova
   Status: New = Invalid

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

Title:
  Option to boot VM only from volume is not available

Status in OpenStack Compute (Nova):
  Invalid
Status in Tempest:
  New

Bug description:
  Issue:
  When service provider wants to use only boot from volume option for booting a 
server then the integration tests fails. No option in Tempest to use only boot 
from volume for booting the server.

  Expected :

  a parameter in Tempest.conf for option of boot_from_volume_only for
  all the tests except for image tests.

  
  $ nova boot --flavor FLAVOR_ID [--image IMAGE_ID] / [ --boot-volume 
BOOTABLE_VOLUME]

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1436314/+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 1439960] [NEW] Users can be assigned the same role in a tenant by create_grant without any error message

2015-04-03 Thread lumeihong 
Public bug reported:

Grant role to user on a project by following command:
curl -H X-Auth_Token:$ADMIN -X PUT  
http://localhost:35357/v3/projects/2fb15258b1f44e05937070be864ed9b1/users/c6b7c33a5cfc45ba8d666b03ba29ea34/roles/7117d8a1a8c04d038c54cf75f6b354b4


it is successful.Then execute the above command again, though it fails, but 
there is no error message prompts.
In fact,it produced a conflict exception,but create_grant didn't process the 
exception.

** Affects: keystone
 Importance: Undecided
 Status: New

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

Title:
  Users can be assigned the same role in a tenant by create_grant
  without any error message

Status in OpenStack Identity (Keystone):
  New

Bug description:
  Grant role to user on a project by following command:
  curl -H X-Auth_Token:$ADMIN -X PUT  
http://localhost:35357/v3/projects/2fb15258b1f44e05937070be864ed9b1/users/c6b7c33a5cfc45ba8d666b03ba29ea34/roles/7117d8a1a8c04d038c54cf75f6b354b4

  
  it is successful.Then execute the above command again, though it fails, but 
there is no error message prompts.
  In fact,it produced a conflict exception,but create_grant didn't process the 
exception.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1439960/+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 1439855] Re: encrypted iSCSI volume fails to attach, name too long

2015-04-03 Thread Matt Riedemann 
*** This bug is a duplicate of bug 1432490 ***
https://bugs.launchpad.net/bugs/1432490

** This bug has been marked a duplicate of bug 1432490
   TestEncryptedCinderVolumes cryptsetup name is too long

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

Title:
  encrypted iSCSI volume fails to attach, name too long

Status in OpenStack Compute (Nova):
  New

Bug description:
  When running the following tempest tests an error occurs in n-cpu:

  
tempest.scenario.test_encrypted_cinder_volumes.TestEncryptedCinderVolumes.test_encrypted_cinder_volumes_cryptsetup
  test_encrypted_cinder_volumes_luks

  This occurred when using devstack with nova at:

  HEAD is now at d0c2684 Merge libvirt: Resize down an instance booted
  from a volume

  Both stack traces below are from n-cpu logs:

  Stack Trace
  
(tempest.scenario.test_encrypted_cinder_volumes.TestEncryptedCinderVolumes.test_encrypted_cinder_volumes_cryptsetup):

  2015-03-27 18:03:07.990 ERROR nova.compute.manager 
[req-cc941973-c038-4bac-a5ca-d516cd5dd33d TestEncryptedCinderVolumes-658052177 
TestEncryptedCinderVolumes-1476988517] [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46] Failed to attach 
2ab47be7-64ac-4d34-a38c-59c5e97e2ec2 at /dev/vdb
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46] Traceback (most recent call last):
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46]   File 
/opt/stack/new/nova/nova/compute/manager.py, line 4735, in _attach_volume
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46] do_check_attach=False, 
do_driver_attach=True)
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46]   File 
/opt/stack/new/nova/nova/virt/block_device.py, line 48, in wrapped
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46] ret_val = method(obj, context, *args, 
**kwargs)
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46]   File 
/opt/stack/new/nova/nova/virt/block_device.py, line 260, in attach
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46] connector)
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46]   File 
/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py, line 85, in 
__exit__
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46] six.reraise(self.type_, self.value, 
self.tb)
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46]   File 
/opt/stack/new/nova/nova/virt/block_device.py, line 251, in attach
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46] device_type=self['device_type'], 
encryption=encryption)
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46]   File 
/opt/stack/new/nova/nova/virt/libvirt/driver.py, line 1065, in attach_volume
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46] 
self._disconnect_volume(connection_info, disk_dev)
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46]   File 
/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py, line 85, in 
__exit__
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46] six.reraise(self.type_, self.value, 
self.tb)
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46]   File 
/opt/stack/new/nova/nova/virt/libvirt/driver.py, line 1052, in attach_volume
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46] encryptor.attach_volume(context, 
**encryption)
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46]   File 
/opt/stack/new/nova/nova/volume/encryptors/cryptsetup.py, line 86, in 
attach_volume
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46] self._open_volume(passphrase, 
**kwargs)
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46]   File 
/opt/stack/new/nova/nova/volume/encryptors/cryptsetup.py, line 71, in 
_open_volume
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46] check_exit_code=True,

[Yahoo-eng-team] [Bug 1439855] Re: encrypted iSCSI volume fails to attach, name too long

2015-04-03 Thread Sean Dague 
This isn't really a dup, because this is about nova failing gracefully I
think.

Can you provide relevant dmesg logs to figure out if this being
triggered in the kernel or if this is something in cryptsetup itself, so
that we can handle this in the right place?

** This bug is no longer a duplicate of bug 1432490
   TestEncryptedCinderVolumes cryptsetup name is too long

** Changed in: nova
   Status: New = Incomplete

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

Title:
  encrypted iSCSI volume fails to attach, name too long

Status in OpenStack Compute (Nova):
  Incomplete

Bug description:
  When running the following tempest tests an error occurs in n-cpu:

  
tempest.scenario.test_encrypted_cinder_volumes.TestEncryptedCinderVolumes.test_encrypted_cinder_volumes_cryptsetup
  test_encrypted_cinder_volumes_luks

  This occurred when using devstack with nova at:

  HEAD is now at d0c2684 Merge libvirt: Resize down an instance booted
  from a volume

  Both stack traces below are from n-cpu logs:

  Stack Trace
  
(tempest.scenario.test_encrypted_cinder_volumes.TestEncryptedCinderVolumes.test_encrypted_cinder_volumes_cryptsetup):

  2015-03-27 18:03:07.990 ERROR nova.compute.manager 
[req-cc941973-c038-4bac-a5ca-d516cd5dd33d TestEncryptedCinderVolumes-658052177 
TestEncryptedCinderVolumes-1476988517] [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46] Failed to attach 
2ab47be7-64ac-4d34-a38c-59c5e97e2ec2 at /dev/vdb
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46] Traceback (most recent call last):
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46]   File 
/opt/stack/new/nova/nova/compute/manager.py, line 4735, in _attach_volume
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46] do_check_attach=False, 
do_driver_attach=True)
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46]   File 
/opt/stack/new/nova/nova/virt/block_device.py, line 48, in wrapped
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46] ret_val = method(obj, context, *args, 
**kwargs)
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46]   File 
/opt/stack/new/nova/nova/virt/block_device.py, line 260, in attach
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46] connector)
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46]   File 
/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py, line 85, in 
__exit__
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46] six.reraise(self.type_, self.value, 
self.tb)
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46]   File 
/opt/stack/new/nova/nova/virt/block_device.py, line 251, in attach
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46] device_type=self['device_type'], 
encryption=encryption)
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46]   File 
/opt/stack/new/nova/nova/virt/libvirt/driver.py, line 1065, in attach_volume
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46] 
self._disconnect_volume(connection_info, disk_dev)
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46]   File 
/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py, line 85, in 
__exit__
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46] six.reraise(self.type_, self.value, 
self.tb)
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46]   File 
/opt/stack/new/nova/nova/virt/libvirt/driver.py, line 1052, in attach_volume
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46] encryptor.attach_volume(context, 
**encryption)
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46]   File 
/opt/stack/new/nova/nova/volume/encryptors/cryptsetup.py, line 86, in 
attach_volume
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46] self._open_volume(passphrase, 
**kwargs)
  2015-03-27 18:03:07.990 29082 TRACE nova.compute.manager [instance: 
a2cccacf-2876-4e94-94e0-dbb3fbf51c46]   File

[Yahoo-eng-team] [Bug 1440107] [NEW] Clearing up project assignments makes assumptions that domain_id != project_id

2015-04-03 Thread Henry Nash 
Public bug reported:

The method delete_project_assignments() in the assignment backends
removes all assignments for a project - although the code fails to set
the type of assignment, and just uses target_id.  This is nearly always
going to be fine, although technically one should also specify the type
of the assignment in the delete (e.g. USER_PROJECT or GROUP_PROJECT).

** Affects: keystone
 Importance: Low
 Assignee: Henry Nash (henry-nash)
 Status: New

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

Title:
  Clearing up project assignments makes assumptions that domain_id !=
  project_id

Status in OpenStack Identity (Keystone):
  New

Bug description:
  The method delete_project_assignments() in the assignment backends
  removes all assignments for a project - although the code fails to set
  the type of assignment, and just uses target_id.  This is nearly
  always going to be fine, although technically one should also specify
  the type of the assignment in the delete (e.g. USER_PROJECT or
  GROUP_PROJECT).

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1440107/+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 1440143] [NEW] [Launch Instance Fix] Duplicate 'detail' class in detail rows causing expand to not work

2015-04-03 Thread Kelly Domico 
Public bug reported:

The detail rows in source and flavor have some duplicate 'detail'
classes which is causing the expand to not work

** Affects: horizon
 Importance: Undecided
 Assignee: Kelly Domico (kelly-domico)
 Status: New

** Changed in: horizon
 Assignee: (unassigned) = Kelly Domico (kelly-domico)

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

Title:
  [Launch Instance Fix] Duplicate 'detail' class in detail rows causing
  expand to not work

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  The detail rows in source and flavor have some duplicate 'detail'
  classes which is causing the expand to not work

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1440143/+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 1440163] [NEW] List images passing visibility as a sort_key returns a 400 response

2015-04-03 Thread Luke Wollney 
Public bug reported:

Overview:
When attempting a list images request passing 'visibility' as a sort_key 
returns a 400 response.

Steps to reproduce:
1) List images passing 'visibility' as a sort_key via:
curl -i 'endpoint/v2/images?sort_key=visibility' -X GET -H Content-Type: 
application/json -H Accept: application/json -H X-Auth-Token: token
2) Notice that a 400 response is returned

Expected:
A list of images sorted by the 'visibility' property value

Actual:
A 400 response is returned

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

Title:
  List images passing visibility as a sort_key returns a 400 response

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

Bug description:
  Overview:
  When attempting a list images request passing 'visibility' as a sort_key 
returns a 400 response.

  Steps to reproduce:
  1) List images passing 'visibility' as a sort_key via:
  curl -i 'endpoint/v2/images?sort_key=visibility' -X GET -H Content-Type: 
application/json -H Accept: application/json -H X-Auth-Token: token
  2) Notice that a 400 response is returned

  Expected:
  A list of images sorted by the 'visibility' property value

  Actual:
  A 400 response is returned

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1440163/+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 1440123] [NEW] keystone-manage fails if optional fernet packages not installed

2015-04-03 Thread Brant Knudson 
Public bug reported:


If I'm not using fernet, so don't install the packages that are only required 
if fernet is used (e.g., cryptography), then all keystone-manage commands will 
fail to run with an exception due to the missing package.

keystone-manage commands that aren't fernet-related should work when the
non-fernet packages are not installed.

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

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

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

Title:
  keystone-manage fails if optional fernet packages not installed

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  
  If I'm not using fernet, so don't install the packages that are only required 
if fernet is used (e.g., cryptography), then all keystone-manage commands will 
fail to run with an exception due to the missing package.

  keystone-manage commands that aren't fernet-related should work when
  the non-fernet packages are not installed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1440123/+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 1440135] [NEW] Cleaning up user/group assignments makes incorrect assumption that user_id != group_id

2015-04-03 Thread Henry Nash 
Public bug reported:

The methods delete_user_assignments() and delete_group_assignments()  in
the assignment backends removes all assignments for a user/group -
although the code fails to set the type of assignment, and just uses
actor_id. This is nearly always going to be fine, although technically
one should also specify the type of the assignment in the delete (e.g.
USER_PROJECT/USER_DOMAIN and USER_PROJECT/GROUP_PROJECT).

** Affects: keystone
 Importance: Low
 Assignee: Henry Nash (henry-nash)
 Status: New

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

Title:
  Cleaning up user/group assignments makes incorrect assumption that
  user_id != group_id

Status in OpenStack Identity (Keystone):
  New

Bug description:
  The methods delete_user_assignments() and delete_group_assignments()
  in the assignment backends removes all assignments for a user/group -
  although the code fails to set the type of assignment, and just uses
  actor_id. This is nearly always going to be fine, although technically
  one should also specify the type of the assignment in the delete (e.g.
  USER_PROJECT/USER_DOMAIN and USER_PROJECT/GROUP_PROJECT).

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1440135/+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 1440165] [NEW] List images passing tags as a sort_key returns a 500 response

2015-04-03 Thread Luke Wollney 
Public bug reported:

Overview:
When attempting a list images request passing 'tags' as a sort_key takes a good 
amount of time to respond and then returns a 500 response.

Steps to reproduce:
1) List images passing 'tags' as a sort_key via:
curl -i 'endpoint/v2/images?sort_key=tags' -X GET -H Content-Type: 
application/json -H Accept: application/json -H X-Auth-Token: token
2) Notice that a 500 response is returned

Expected:
A list of images sorted by the 'tags' property value

Actual:
A 500 response is returned

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

Title:
  List images passing tags as a sort_key returns a 500 response

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

Bug description:
  Overview:
  When attempting a list images request passing 'tags' as a sort_key takes a 
good amount of time to respond and then returns a 500 response.

  Steps to reproduce:
  1) List images passing 'tags' as a sort_key via:
  curl -i 'endpoint/v2/images?sort_key=tags' -X GET -H Content-Type: 
application/json -H Accept: application/json -H X-Auth-Token: token
  2) Notice that a 500 response is returned

  Expected:
  A list of images sorted by the 'tags' property value

  Actual:
  A 500 response is returned

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1440165/+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 1440120] [NEW] List images passing protected as a sort_key and a marker returns a 500 response

2015-04-03 Thread Luke Wollney 
Public bug reported:

Overview:
When attempting a list images request passing 'protected' as a sort_key along 
with an image id as the marker returns a 500 response.

Steps to reproduce:
1) List images passing 'protected' as a sort_key and an image id as the marker 
via:
curl -i 'endpoint/v2/images?sort_key=protectedmarker=image id' -X GET -H 
Content-Type: application/json -H Accept: application/json -H 
X-Auth-Token: token
2) Notice that a 500 response is returned

Expected:
A list of images sorted by the 'protected' property value starting with the 
image passed in as the marker

Actual:
A 500 response is returned

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

Title:
  List images passing protected as a sort_key and a marker returns a 500
  response

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

Bug description:
  Overview:
  When attempting a list images request passing 'protected' as a sort_key along 
with an image id as the marker returns a 500 response.

  Steps to reproduce:
  1) List images passing 'protected' as a sort_key and an image id as the 
marker via:
  curl -i 'endpoint/v2/images?sort_key=protectedmarker=image id' -X GET -H 
Content-Type: application/json -H Accept: application/json -H 
X-Auth-Token: token
  2) Notice that a 500 response is returned

  Expected:
  A list of images sorted by the 'protected' property value starting with the 
image passed in as the marker

  Actual:
  A 500 response is returned

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1440120/+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 1440170] [NEW] List images passing id as a sort_key returns an incorrectly ordered list of images

2015-04-03 Thread Luke Wollney 
Public bug reported:

Overview:
When attempting a list images request passing 'id' as a sort_key returns a list 
of images that are not in the correct order.  Even when passing the sort_dir of 
asc or desc, the order is still incorrect.

Steps to reproduce:
1) List images passing 'id' as a sort_key via:
curl -i 'endpoint/v2/images?sort_key=id' -X GET -H Content-Type: 
application/json -H Accept: application/json -H X-Auth-Token: token
2) Notice that the list of images returned is not in the correct order
3) List images passing 'id' as a sort_key and asc or desc as the sort_dir via:
curl -i 'endpoint/v2/images?sort_key=idsort_dir=asc' -X GET -H 
Content-Type: application/json -H Accept: application/json -H 
X-Auth-Token: token
4) Notice that the list of images returned is still not in the correct order

Expected:
A list of images correctly sorted by the 'id' property value

Actual:
A list of images is returned, but not correctly ordered, either asc or desc

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

Title:
  List images passing id as a sort_key returns an incorrectly ordered
  list of images

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

Bug description:
  Overview:
  When attempting a list images request passing 'id' as a sort_key returns a 
list of images that are not in the correct order.  Even when passing the 
sort_dir of asc or desc, the order is still incorrect.

  Steps to reproduce:
  1) List images passing 'id' as a sort_key via:
  curl -i 'endpoint/v2/images?sort_key=id' -X GET -H Content-Type: 
application/json -H Accept: application/json -H X-Auth-Token: token
  2) Notice that the list of images returned is not in the correct order
  3) List images passing 'id' as a sort_key and asc or desc as the sort_dir via:
  curl -i 'endpoint/v2/images?sort_key=idsort_dir=asc' -X GET -H 
Content-Type: application/json -H Accept: application/json -H 
X-Auth-Token: token
  4) Notice that the list of images returned is still not in the correct order

  Expected:
  A list of images correctly sorted by the 'id' property value

  Actual:
  A list of images is returned, but not correctly ordered, either asc or desc

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1440170/+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 1440183] [NEW] DBDeadlock on subnet allocation

2015-04-03 Thread Armando Migliaccio 
Public bug reported:

It looks like this is starting to hit:

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

** Affects: neutron
 Importance: High
 Status: Confirmed

** Description changed:

+ It looks like this is starting to hit:
+ 
  
http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiREJEZWFkbG9jazogKE9wZXJhdGlvbmFsRXJyb3IpICgxMjA1LCAnTG9jayB3YWl0IHRpbWVvdXQgZXhjZWVkZWQ7IHRyeSByZXN0YXJ0aW5nIHRyYW5zYWN0aW9uJylcIiIsImZpZWxkcyI6W10sIm9mZnNldCI6MCwidGltZWZyYW1lIjoiNjA0ODAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTQyODA5MDM4MzgzMSwibW9kZSI6IiIsImFuYWx5emVfZmllbGQiOiIifQ==

** Changed in: neutron
   Importance: Undecided = High

** Changed in: neutron
   Status: New = Confirmed

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

Title:
  DBDeadlock on subnet allocation

Status in OpenStack Neutron (virtual network service):
  Confirmed

Bug description:
  It looks like this is starting to hit:

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1440183/+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 1440221] [NEW] need ipv6 tests for lbaasv2

2015-04-03 Thread Doug Wiegley 
Public bug reported:

All of our tests are ipv4, but we should support v6 at this point. Let's
test it.

** Affects: neutron
 Importance: Undecided
 Assignee: Franklin Naval (franknaval)
 Status: New


** Tags: lbaas

** Changed in: neutron
 Assignee: (unassigned) = Franklin Naval (franknaval)

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

Title:
  need ipv6 tests for lbaasv2

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  All of our tests are ipv4, but we should support v6 at this point.
  Let's test it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1440221/+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 1438520] Re: cloud-init on vivid upgrade causes sigterm, which aborts 'runcmd' execution

2015-04-03 Thread Launchpad Bug Tracker 
This bug was fixed in the package cloud-init - 0.7.7~bzr1088-0ubuntu2

---
cloud-init (0.7.7~bzr1088-0ubuntu2) vivid; urgency=medium

  [ Didier Roche ]
  * Don't start or restart cloud-init services on install and upgrade
(LP: #1438520)

  [ Scott Moser ]
  * d/control: Build-Depends on iproute2 (tests)
  * d/control: Only Recommend (not both Depend and Recommend)
software-properties-common
 -- Scott Moser smo...@ubuntu.com   Fri, 03 Apr 2015 11:13:28 -0400

** Changed in: cloud-init (Ubuntu)
   Status: Confirmed = Fix Released

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

Title:
  cloud-init on vivid upgrade causes sigterm, which aborts 'runcmd'
  execution

Status in Init scripts for use on cloud images:
  Confirmed
Status in cloud-init package in Ubuntu:
  Fix Released

Bug description:
  I used an openstack infrastructure with a vivid beta2 image.  End
  result, if there is cloud-init upgrade available, it installs and
  abort parts of the cloud-init execution.  (bad news for my user
  scripts!)  I'm not sure of all the fallout, but at least my 'runcmd'
  section was not executed (grep the logs for 'runcmd').

  From cloud-init-output.log:

  Preparing to unpack .../cryptsetup-bin_2%3a1.6.1-1ubuntu7_amd64.deb ...^M
  Unpacking cryptsetup-bin (2:1.6.1-1ubuntu7) over (2:1.6.1-1ubuntu5) ...^M
  Preparing to unpack .../cryptsetup_2%3a1.6.1-1ubuntu7_amd64.deb ...^M
  Unpacking cryptsetup (2:1.6.1-1ubuntu7) over (2:1.6.1-1ubuntu5) ...^M
  Preparing to unpack .../cloud-init_0.7.7~bzr1087-0ubuntu1_all.deb ...^M
  Cloud-init v. 0.7.7 running 'modules:final' at Tue, 31 Mar 2015 05:09:42 
+. Up 848.15 seconds.
  Cloud-init v. 0.7.7 finished at Tue, 31 Mar 2015 05:09:44 +. Datasource 
DataSourceOpenStack [net,ver=2].  Up 850.19 seconds

  From cloud-init.log:

  Mar 31 04:57:38 ubuntu [CLOUDINIT] util.py[DEBUG]: Running command 
['eatmydata', 'apt-get', '--option=Dpkg::Options::=--force-confold', 
'--option=Dpkg::options::=--force-unsafe-io', '--assume-yes', '--quiet', 
'dist-upgrade'] with allowed return codes [0] (shell=False, capture=False)
  Mar 31 05:09:41 ubuntu [CLOUDINIT] util.py[DEBUG]: Cloud-init 0.7.7 received 
SIGTERM, exiting...#012  Filename: /usr/lib/python3.4/subprocess.py#012  
Function: _eintr_retry_call#012  Line number: 491#012Filename: 
/usr/lib/python3.4/subprocess.py#012Function: _try_wait#012Line number: 
1514#012  Filename: /usr/lib/python3.4/subprocess.py#012  Function: 
wait#012  Line number: 1566
  Mar 31 05:09:41 ubuntu [CLOUDINIT] util.py[DEBUG]: apt-upgrade [eatmydata 
apt-get --option=Dpkg::Options::=--force-confold 
--option=Dpkg::options::=--force-unsafe-io --assume-yes --quiet dist-upgrade] 
took 722.766 seconds
  Mar 31 05:09:41 ubuntu [CLOUDINIT] util.py[DEBUG]: Reading from /proc/uptime 
(quiet=False)
  Mar 31 05:09:41 ubuntu [CLOUDINIT] util.py[DEBUG]: Read 12 bytes from 
/proc/uptime
  Mar 31 05:09:41 ubuntu [CLOUDINIT] util.py[DEBUG]: cloud-init mode 'modules' 
took 761.227 seconds (761.23)
  Mar 31 05:09:42 ubuntu [CLOUDINIT] util.py[DEBUG]: Cloud-init v. 0.7.7 
running 'modules:final' at Tue, 31 Mar 2015 05:09:42 +. Up 848.15 seconds.
  Mar 31 05:09:44 ubuntu [CLOUDINIT] stages.py[DEBUG]: Using distro class 
class 'cloudinit.distros.ubuntu.Distro'
  Mar 31 05:09:44 ubuntu [CLOUDINIT] stages.py[DEBUG]: Running module 
rightscale_userdata (module 'cloudinit.config.cc_rightscale_userdata' from 
'/usr/lib/python3/dist-packages/cloudinit/config/cc_rightscale_userdata.py') 
with frequency once-per-instance


  I'll attach full cloud-init logs and the userdata.  I used the
  following command to boot the instance:

  nova boot --key-name dpb --user-data ~/test.txt --image
  fc7aedfd-f465-48b9-9fc6-c826f3a0e81b --flavor 2 vivid-test

  and the image is this:

  ubuntu-released/ubuntu-
  vivid-15.04-beta2-amd64-server-20150325-disk1.img

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1438520/+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 1440192] [NEW] DB Deadlock: Lock wait timeout exceeded; try restarting transaction') 'INSERT INTO ipallocations

2015-04-03 Thread Dane LeBlanc 
Public bug reported:

If DVR is enabled, and the following 2 Tempest tests are run
concurrently:

tempest.api.network.test_dhcp_ipv6.NetworksTestDHCPv6.test_dhcp_stateful_router[id-e98f65db-68f4-4330-9fea-abd8c5192d4d]
tempest.api.network.test_dhcp_ipv6.NetworksTestDHCPv6.test_dhcpv6_64_subnets[id-4256c61d-c538-41ea-9147-3c450c36669e]

then the test_dhcpv6_64_subnets test case will fail intermittently
(about 1 in 6 tries) with the following error in the Neutron server log:

2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource DBDeadlock:
(OperationalError) (1205, 'Lock wait timeout exceeded; try restarting
transaction') 'INSERT INTO ipallocations (port_id, ip_address,
subnet_id, network_id) VALUES (%s, %s, %s, %s)' ('96c6cc59-5ebd-
4f91-bf28-ca60b31f71e1', '2003::f816:3eff:fe1e:ba9e',
'4a339f40-6038-47c7-90e4-338fb4d14d6b', 'b718484d-5e8a-4ad7-bcfa-
668d519942b7')

And the following traceback is observed:
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource Traceback (most recent 
call last):
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource   File 
/opt/stack/neutron/neutron/api/v2/resource.py, line 83, in resource
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource result = 
method(request=request, **args)
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource   File 
/opt/stack/neutron/neutron/api/v2/base.py, line 461, in create
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource obj = 
obj_creator(request.context, **kwargs)
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource   File 
/opt/stack/neutron/neutron/plugins/ml2/plugin.py, line 791, in create_subnet
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource result, mech_context 
= self._create_subnet_db(context, subnet)
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource   File 
/opt/stack/neutron/neutron/plugins/ml2/plugin.py, line 782, in 
_create_subnet_db
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource result = 
super(Ml2Plugin, self).create_subnet(context, subnet)
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource   File 
/opt/stack/neutron/neutron/db/db_base_plugin_v2.py, line 1348, in 
create_subnet
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource return 
self._create_subnet_from_implicit_pool(context, subnet)
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource   File 
/opt/stack/neutron/neutron/db/db_base_plugin_v2.py, line 1284, in 
_create_subnet_from_implicit_pool
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource 
self._add_auto_addrs_on_network_ports(context, subnet)
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py, line 470, 
in __exit__
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource self.rollback()
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/sqlalchemy/util/langhelpers.py, line 
60, in __exit__
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource 
compat.reraise(exc_type, exc_value, exc_tb)
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py, line 467, 
in __exit__
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource self.commit()
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py, line 377, 
in commit
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource self._prepare_impl()
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py, line 357, 
in _prepare_impl
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource self.session.flush()
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py, line 1919, 
in flush
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource self._flush(objects)
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py, line 2037, 
in _flush
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource 
transaction.rollback(_capture_exception=True)
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/sqlalchemy/util/langhelpers.py, line 
60, in __exit__
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource 
compat.reraise(exc_type, exc_value, exc_tb)
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py, line 2001, 
in _flush
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource 
flush_context.execute()
m2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource   File 
/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/unitofwork.py, line 
372, in execute
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource rec.execute(self)
2015-04-03 15:29:14.696 TRACE neutron.api.v2.resource   File

[Yahoo-eng-team] [Bug 1419070] Re: Dropdown for Domains and Projects always shows Default for Domains

2015-04-03 Thread Brad Pokorny 
After more work with domains, I found the dropdown wasn't changing
because it shows the user domain name, rather than the project domain
name.  If the user is in a domain other than default, I validated the
dropdown does reflect that.

I'll invalidate this bug.

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

Title:
  Dropdown for Domains and Projects always shows Default for Domains

Status in OpenStack Dashboard (Horizon):
  Invalid

Bug description:
  After logging into Horizon with a domain other than Default, the
  dropdown for Domains and Projects always shows Default for the
  Domains.  It would make more sense to users if it showed the domain
  they logged in with.

  I've been doing some testing with
  https://review.openstack.org/#/c/141153/ and
  https://review.openstack.org/#/c/148082/ , and this situation still
  exists - even though we can now get a token scoped to the domain the
  user logged in with.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1419070/+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 1440185] [NEW] Identity provider create fails if remote_id is not set

2015-04-03 Thread Nathan Kinder 
Public bug reported:

When support for multiple remote_ids was added
(https://review.openstack.org/#/c/152156/), a prolem was introduced
where Keystone will return a 400 response when an identity provider is
created without a remote_id.  The remote_id is supposed to be optional.
Here is what the problem looks like using python-openstackclient:

[root@rdo ~]# openstack --os-auth-url http://rdo.rdodom.test:5000/v3 
--os-user-domain-name default \
--os-username admin --os-password password --os-project-domain-name default 
--os-project-name admin \
--os-identity-api-version 3 identity provider create --enable test
ERROR: openstack 'NoneType' object is not iterable (HTTP 400) (Request-ID: 
req-172efcf5-6e1b-4059-99f1-44acb069067a)

The problem is that the dict that is passed into
IdentityProviderModel.from_dict() looks like this:

  {u'enabled': True, u'description': None, u'remote_ids': None}

We pop the 'remote_ids' item from the dict to create remote_ids_list,
but this results in the list being None.  We then try to iterate the
list, which triggers an exception that leads to the 400 error.  We need
to fix the way we initialize the list.

** Affects: keystone
 Importance: Undecided
 Assignee: Nathan Kinder (nkinder)
 Status: In Progress

** Changed in: keystone
 Assignee: (unassigned) = Nathan Kinder (nkinder)

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

Title:
  Identity provider create fails if remote_id is not set

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  When support for multiple remote_ids was added
  (https://review.openstack.org/#/c/152156/), a prolem was introduced
  where Keystone will return a 400 response when an identity provider is
  created without a remote_id.  The remote_id is supposed to be
  optional.  Here is what the problem looks like using python-
  openstackclient:

  [root@rdo ~]# openstack --os-auth-url http://rdo.rdodom.test:5000/v3 
--os-user-domain-name default \
  --os-username admin --os-password password --os-project-domain-name 
default --os-project-name admin \
  --os-identity-api-version 3 identity provider create --enable test
  ERROR: openstack 'NoneType' object is not iterable (HTTP 400) (Request-ID: 
req-172efcf5-6e1b-4059-99f1-44acb069067a)

  The problem is that the dict that is passed into
  IdentityProviderModel.from_dict() looks like this:

{u'enabled': True, u'description': None, u'remote_ids': None}

  We pop the 'remote_ids' item from the dict to create remote_ids_list,
  but this results in the list being None.  We then try to iterate the
  list, which triggers an exception that leads to the 400 error.  We
  need to fix the way we initialize the list.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1440185/+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 1440265] Re: CloudStack sshkey reset

2015-04-03 Thread pdion891 
** Also affects: cloud-init
   Importance: Undecided
   Status: New

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

Title:
  CloudStack sshkey reset

Status in Init scripts for use on cloud images:
  New
Status in cloud-init package in Ubuntu:
  New

Bug description:
  CloudStack provide capability to reset SSH keys for an existing VM
  with the API: resetSSHKeyForVirtualMachine [1]

  creating an Instance with SSHkey currently work with cloud-init. But,
  CloudStack have the capability to reset it, the VM must be shutdown,
  sshkey replaced then the vm restart, current cloud-init does not
  update the user sshkey using the new one available from the dhcp
  server.

  tested with cloud-init-0.7.7

  current method to mitigate this behavior is to use cloudstack scripts
  into the /var/lib/cloud/scripts/per-boot/  which does not benefit from
  cloud-init configuration capabilities.

  
  [1] 
http://cloudstack.apache.org/docs/api/apidocs-4.5/root_admin/resetSSHKeyForVirtualMachine.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1440265/+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 1440244] [NEW] Horizon throws unauthorized error for cloud admin when domain feature is setup

2015-04-03 Thread Sumanth 
Public bug reported:

I have a devstack running following components
1.keystone
2.heat
3.nova
4.horizon
5.cinder

For this open stack setup I wanted to enable domain feature, define admin 
boundaries. To enable the domains, these changes were made :
1. Changed the token format from PKI to UUID
2. added auth_version = v3.0 under [auth_token:fillter] section of all the 
api-paste.ini file of all the services
3. updated the endpoints to point to v3
4. restarted all the services
5. Changed the default keystone policy.json with policy.v3sample.json and set 
the admin_domain_id to default

I horizons local_settings.py file
1. set the OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT to True
2. updated the enpoint to point to localhost:5000/v3

after all these changes when I try to login into the default domain with
admin credentials , i get ubale retirve domain list , unable retrive
project list errors horizons dashboard.

** Affects: horizon
 Importance: Undecided
 Status: New


** Tags: cloudadmin domain horizon

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

Title:
  Horizon throws unauthorized error for cloud admin when domain feature
  is setup

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  I have a devstack running following components
  1.keystone
  2.heat
  3.nova
  4.horizon
  5.cinder

  For this open stack setup I wanted to enable domain feature, define admin 
boundaries. To enable the domains, these changes were made :
  1. Changed the token format from PKI to UUID
  2. added auth_version = v3.0 under [auth_token:fillter] section of all the 
api-paste.ini file of all the services
  3. updated the endpoints to point to v3
  4. restarted all the services
  5. Changed the default keystone policy.json with policy.v3sample.json and set 
the admin_domain_id to default

  I horizons local_settings.py file
  1. set the OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT to True
  2. updated the enpoint to point to localhost:5000/v3

  after all these changes when I try to login into the default domain
  with admin credentials , i get ubale retirve domain list , unable
  retrive project list errors horizons dashboard.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1440244/+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 1426543] Re: Spike in DBDeadlock errors in update_floatingip_statuses since 2/27

2015-04-03 Thread Armando Migliaccio 
** No longer affects: nova

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

Title:
  Spike in DBDeadlock errors in update_floatingip_statuses since 2/27

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

Bug description:
  http://logs.openstack.org/40/122240/19/gate/gate-tempest-dsvm-neutron-
  full/4ef0a02/logs/screen-n-cpu.txt.gz?level=TRACE#_2015-02-27_18_05_22_444

  2015-02-27 18:05:22.444 8433 ERROR nova.compute.manager [-] Instance failed 
network setup after 1 attempt(s)
  2015-02-27 18:05:22.444 8433 TRACE nova.compute.manager Traceback (most 
recent call last):
  2015-02-27 18:05:22.444 8433 TRACE nova.compute.manager   File 
/opt/stack/new/nova/nova/compute/manager.py, line 1684, in 
_allocate_network_async
  2015-02-27 18:05:22.444 8433 TRACE nova.compute.manager 
dhcp_options=dhcp_options)
  2015-02-27 18:05:22.444 8433 TRACE nova.compute.manager   File 
/opt/stack/new/nova/nova/network/neutronv2/api.py, line 395, in 
allocate_for_instance
  2015-02-27 18:05:22.444 8433 TRACE nova.compute.manager net_ids, 
neutron=neutron)
  2015-02-27 18:05:22.444 8433 TRACE nova.compute.manager   File 
/opt/stack/new/nova/nova/network/neutronv2/api.py, line 226, in 
_get_available_networks
  2015-02-27 18:05:22.444 8433 TRACE nova.compute.manager nets = 
neutron.list_networks(**search_opts).get('networks', [])
  2015-02-27 18:05:22.444 8433 TRACE nova.compute.manager   File 
/usr/local/lib/python2.7/dist-packages/neutronclient/v2_0/client.py, line 99, 
in with_params
  2015-02-27 18:05:22.444 8433 TRACE nova.compute.manager ret = 
self.function(instance, *args, **kwargs)
  2015-02-27 18:05:22.444 8433 TRACE nova.compute.manager   File 
/usr/local/lib/python2.7/dist-packages/neutronclient/v2_0/client.py, line 
524, in list_networks
  2015-02-27 18:05:22.444 8433 TRACE nova.compute.manager **_params)
  2015-02-27 18:05:22.444 8433 TRACE nova.compute.manager   File 
/usr/local/lib/python2.7/dist-packages/neutronclient/v2_0/client.py, line 
304, in list
  2015-02-27 18:05:22.444 8433 TRACE nova.compute.manager for r in 
self._pagination(collection, path, **params):
  2015-02-27 18:05:22.444 8433 TRACE nova.compute.manager   File 
/usr/local/lib/python2.7/dist-packages/neutronclient/v2_0/client.py, line 
317, in _pagination
  2015-02-27 18:05:22.444 8433 TRACE nova.compute.manager res = 
self.get(path, params=params)
  2015-02-27 18:05:22.444 8433 TRACE nova.compute.manager   File 
/usr/local/lib/python2.7/dist-packages/neutronclient/v2_0/client.py, line 
290, in get
  2015-02-27 18:05:22.444 8433 TRACE nova.compute.manager headers=headers, 
params=params)
  2015-02-27 18:05:22.444 8433 TRACE nova.compute.manager   File 
/usr/local/lib/python2.7/dist-packages/neutronclient/v2_0/client.py, line 
267, in retry_request
  2015-02-27 18:05:22.444 8433 TRACE nova.compute.manager headers=headers, 
params=params)
  2015-02-27 18:05:22.444 8433 TRACE nova.compute.manager   File 
/usr/local/lib/python2.7/dist-packages/neutronclient/v2_0/client.py, line 
197, in do_request
  2015-02-27 18:05:22.444 8433 TRACE nova.compute.manager 
content_type=self.content_type())
  2015-02-27 18:05:22.444 8433 TRACE nova.compute.manager   File 
/usr/local/lib/python2.7/dist-packages/neutronclient/client.py, line 172, in 
do_request
  2015-02-27 18:05:22.444 8433 TRACE nova.compute.manager **kwargs)
  2015-02-27 18:05:22.444 8433 TRACE nova.compute.manager   File 
/usr/local/lib/python2.7/dist-packages/neutronclient/client.py, line 108, in 
_cs_request
  2015-02-27 18:05:22.444 8433 TRACE nova.compute.manager raise 
exceptions.ConnectionFailed(reason=e)
  2015-02-27 18:05:22.444 8433 TRACE nova.compute.manager ConnectionFailed: 
Connection to neutron failed: HTTPConnectionPool(host='127.0.0.1', port=9696): 
Max retries exceeded with url: 
/v2.0/networks.json?tenant_id=1e707ab2d2be40a1902f3352c91a615ashared=False 
(Caused by ReadTimeoutError(HTTPConnectionPool(host='127.0.0.1', port=9696): 
Read timed out. (read timeout=30),))
  2015-02-27 18:05:22.444 8433 TRACE nova.compute.manager 


  http://goo.gl/UMI2vZ

  120 hits in the last 24 hours.  There aren't any new python-
  neutronclient releases in that time so that's not it and there are no
  changes to nova.network.neutronv2 in the last 24 hours, so have to
  look at recent compute manager changes.

  There were a few releases of the requests library this week but those
  were on 2/23 and 2/24 so if that was it we should have seen this by
  now.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1426543/+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 1435276] Re: Add simultaneous v2 and v3 API policy support

2015-04-03 Thread Morgan Fainberg 
V2 will not be changed at this point the API and how it handles
authorization for actions is frozen. Development focus is on V3. We have
active bugs/tasks to make the V3 cloud policy the default.

I am closing this bug as won't fix as we aren't going to change V2 API
in a meaningful way unless it is to address a critical security issue.

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

Title:
  Add simultaneous v2 and v3 API policy support

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

Bug description:
  Default policy.json file in Keystone is focused on v2 API nowadays.
  From the (Tempest) testing point-of-view we need to test both
  supported API's simultaneously, which can not be done so far (without
  manual intervention, one API at the time). Automated testing of
  identity v2 and v3 API is done with default v2 policy.json file in
  Tempest, which is seriously limited and doesn't count with v3 model at
  all (domain concepts and scoping, admin role, etc.).

  Would it be possible to either go with the new
  policy.v3cloudsample.json file as default (if it's of course backward-
  compatible with v2) or use different policy file for different
  keystone API running at the same time? Without some solution, we can
  not properly test majority of v3 API functionality automatically.

  This approach could help with issues here:
  
https://blueprints.launchpad.net/tempest/+spec/multi-keystone-api-version-tests
  https://bugs.launchpad.net/keystone/+bug/968696 (admin-ness not properly 
scoped)

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1435276/+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 1440263] Re: cloudstack reset password not working

2015-04-03 Thread pdion891 
** Also affects: cloud-init
   Importance: Undecided
   Status: New

** Summary changed:

- cloudstack reset password not working
+ CloudStack reset password not working

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

Title:
  CloudStack reset password not working

Status in Init scripts for use on cloud images:
  New
Status in cloud-init package in Ubuntu:
  New

Bug description:
  CloudStack provide password reset for existing VM [1]. when generating
  a new random password for user using the cloudstack API:
  resetPasswordForVirtualMachine, it is not considered by cloud-init at
  the restart of the VM.

  This has been experienced with cloud-init 0.7.7

  [1]
  
http://cloudstack.apache.org/docs/api/apidocs-4.5/root_admin/resetPasswordForVirtualMachine.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1440263/+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 1402477] Re: Live migration of volume backed instances broken because the table of block_device_mapping was updated incorrect

2015-04-03 Thread Launchpad Bug Tracker 
[Expired for OpenStack Compute (nova) because there has been no activity
for 60 days.]

** Changed in: nova
   Status: Incomplete = Expired

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

Title:
   Live migration of volume backed instances broken because  the table
  of block_device_mapping was updated incorrect

Status in OpenStack Compute (Nova):
  Expired

Bug description:
  1、 Live migration of volume backed instances
  2、at pre_live_migration function,  the table of block_device_mapping has been 
updated as destination  host volume lun information
  3、at /nova/compute/manager.py  _post_live_migration function， when call  the 
funfunction 
   block_device_info = self._get_instance_block_device_info( ctxt, 
instance, bdms) , because the  Parameters is incorrect , the 
   table of block_device_mapping will be changed as the source host volume 
lun information. 
  4、the next step ,when run the function /nova/compute/manager.py  
post_live_migration_at_destination ,will query volume lun connection from the 
table of block_device_mapping, but  the table has been updated as  source host 
volume lun information,so
  the destination  host  run the under function will failed. :
self.volume_driver_method('connect_volume',
 connection_info,
 disk_dev)

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1402477/+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 1438469] Re: auth_version config not used

2015-04-03 Thread Morgan Fainberg 
** Also affects: keystonemiddleware
   Importance: Undecided
   Status: New

** Changed in: keystone
   Status: New = Invalid

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

Title:
  auth_version config not used

Status in OpenStack Identity (Keystone):
  Invalid
Status in OpenStack Identity  (Keystone) Middleware:
  New

Bug description:
  When auth_version is set to be v3.0 in glance-api.conf, I see this in
  the logs Auth Token proceeding with requested v3.0 apis but in the
  very next debug log I see that the authentication request actually
  appends v2.0 to the identity url, which seems incorrect [1].

  2015-03-31 00:52:13.928 254 INFO keystonemiddleware.auth_token [-] Auth Token 
proceeding with requested v3.0 apis
  2015-03-31 00:52:13.928 254 DEBUG keystoneclient.auth.identity.v2 [-] Making 
authentication request to https://keystone server:35357/v2.0/tokens 
get_auth_ref 
/usr/lib/python2.7/site-packages/keystoneclient/auth/identity/v2.py:76

  Relevant config from glance-api.conf:

  [keystone_authtoken]
  identity_uri = https://keystone server:35357
  admin_user = glance
  admin_password =admin_password
  auth_version = v3.0

  [1]
  
https://github.com/openstack/keystonemiddleware/blob/02abaa1d2711a3d5fc0dd020f05133618e5b7dde/keystonemiddleware/auth_token.py#L548

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1438469/+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 1435396] Re: No notifications for role grants using v2

2015-04-03 Thread Tristan Cacqueray 
Since this report concerns a possible security risk, an incomplete
security advisory task has been added while the core security reviewers
for the affected project or projects confirm the bug and discuss the
scope of any vulnerability along with potential solutions.

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

** Changed in: ossa
   Status: New = Incomplete

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

Title:
  No notifications for role grants using v2

Status in OpenStack Identity (Keystone):
  In Progress
Status in OpenStack Security Advisories:
  Incomplete

Bug description:
  
  If you use the v3 API to add or remove role grants, you get notifications 
that it happened, but if you use the v2.0 API, you don't get notifications.

  Keystone needs to send notifications when the v2 API is used, also.

  For example, start with devstack, then grant a role:

  $ keystone user-role-add --user demo --tenant admin --role admin
 - gets a notification for identity.authenticate, but none for 
identity.created.role_assignment

  Same for revoke:

  $ keystone user-role-remove --user demo --tenant admin --role admin
 - gets a notification for identity.authenticate, but none for 
identity.deleted.role_assignment

  v3 works fine:

  $ curl -X PUT -H X-Auth-Token: $TOKEN
  http://localhost:5000/v3/projects/$PROJECT_ID/users/$USER_ID/roles/$ROLE_ID

  $ curl -X DELETE -H X-Auth-Token: $TOKEN
  http://localhost:5000/v3/projects/$PROJECT_ID/users/$USER_ID/roles/$ROLE_ID

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1435396/+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 1440096] [NEW] Rename Util spec file to align with convention

2015-04-03 Thread Matt Borland 
Public bug reported:

The spec (test) file: 
  horizon/static/horizon/tests/jasmine/utilsSpec.js
should be named to match the format '*.spec.js' like other such files.

This makes it easier to differentiate from source code in wildcard
searches, etc.

** Affects: horizon
 Importance: Undecided
 Assignee: Matt Borland (palecrow)
 Status: In Progress

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

Title:
  Rename Util spec file to align with convention

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  The spec (test) file: 
horizon/static/horizon/tests/jasmine/utilsSpec.js
  should be named to match the format '*.spec.js' like other such files.

  This makes it easier to differentiate from source code in wildcard
  searches, etc.

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