[Yahoo-eng-team] [Bug 1266175] [NEW] 'Import contextlib should be in the section with standard python libraries

2014-01-05 Thread Gary Kotton 
Public bug reported:

There are a number of cases when the import is in the wrong section

** Affects: nova
 Importance: Low
 Assignee: Gary Kotton (garyk)
 Status: In Progress

** Changed in: nova
   Importance: Undecided = Low

** Changed in: nova
 Assignee: (unassigned) = Gary Kotton (garyk)

** Changed in: nova
Milestone: None = icehouse-2

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

Title:
  'Import contextlib should be in the section with standard python
  libraries

Status in OpenStack Compute (Nova):
  In Progress

Bug description:
  There are a number of cases when the import is in the wrong section

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1266175/+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 1266220] [NEW] Unit tests fail when run from symlinked directory

2014-01-05 Thread Ana Krivokapić 
Public bug reported:

E.g, horizon git tree is located at /opt/stack/horizon, and there is a
symlink in user's home directory which points to the horizon git tree:
~/horizon - /opt/stack/horizon. Then cd ~/horizon followed by
./run_tests.sh fails:

FAIL: test_customize_dashboard (horizon.test.tests.base.CustomPanelTests)
--
Traceback (most recent call last):
  File /home/akrivoka/horizon/horizon/test/tests/base.py, line 382, in 
test_customize_dashboard
self.assertEqual(cats.name, WildCats)
AssertionError: 'Cats' != 'WildCats'
'Cats' != 'WildCats' = '%s != %s' % (safe_repr('Cats'), 
safe_repr('WildCats'))
'Cats' != 'WildCats' = self._formatMessage('Cats' != 'WildCats', 
'Cats' != 'WildCats')
  raise self.failureException('Cats' != 'WildCats')


==
FAIL: test_customized_permissions 
(horizon.test.tests.base.CustomPermissionsTests)
--
Traceback (most recent call last):
  File /home/akrivoka/horizon/horizon/test/tests/base.py, line 420, in 
test_customized_permissions
self.assertEqual(resp.status_code, 302)
AssertionError: 200 != 302
'200 != 302' = '%s != %s' % (safe_repr(200), safe_repr(302))
'200 != 302' = self._formatMessage('200 != 302', '200 != 302')
  raise self.failureException('200 != 302')

** Affects: horizon
 Importance: Undecided
 Assignee: Ana Krivokapić (akrivoka)
 Status: New

** Changed in: horizon
 Assignee: (unassigned) = Ana Krivokapić (akrivoka)

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

Title:
  Unit tests fail when run from symlinked directory

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  E.g, horizon git tree is located at /opt/stack/horizon, and there is a
  symlink in user's home directory which points to the horizon git tree:
  ~/horizon - /opt/stack/horizon. Then cd ~/horizon followed by
  ./run_tests.sh fails:

  FAIL: test_customize_dashboard (horizon.test.tests.base.CustomPanelTests)
  --
  Traceback (most recent call last):
File /home/akrivoka/horizon/horizon/test/tests/base.py, line 382, in 
test_customize_dashboard
  self.assertEqual(cats.name, WildCats)
  AssertionError: 'Cats' != 'WildCats'
  'Cats' != 'WildCats' = '%s != %s' % (safe_repr('Cats'), 
safe_repr('WildCats'))
  'Cats' != 'WildCats' = self._formatMessage('Cats' != 'WildCats', 
'Cats' != 'WildCats')
raise self.failureException('Cats' != 'WildCats')
  

  ==
  FAIL: test_customized_permissions 
(horizon.test.tests.base.CustomPermissionsTests)
  --
  Traceback (most recent call last):
File /home/akrivoka/horizon/horizon/test/tests/base.py, line 420, in 
test_customized_permissions
  self.assertEqual(resp.status_code, 302)
  AssertionError: 200 != 302
  '200 != 302' = '%s != %s' % (safe_repr(200), safe_repr(302))
  '200 != 302' = self._formatMessage('200 != 302', '200 != 302')
raise self.failureException('200 != 302')

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1266220/+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 1266262] Re: creating a large ext3 ephemeral disk filesystem is much slower than ext4

2014-01-05 Thread Clint Byrum 
** Also affects: nova
   Importance: Undecided
   Status: New

** Description changed:

  ext3 is more generally available than ext4, but creating an ext3
  filesystem involves a lot more writing than ext3. The only reason to
  retain ext3 is to retain backward compatibility with very old guest OS's
  or OS's which have chosen not to support ext4 such as SLES.
  
  A plan should be made to deprecate ext3 support in Nova at some point.
  For TripleO we are not supporting deploying OpenStack itself on older
  OS's like this, thus we should change this setting in our baremetal
  cloud(s) to be ext4.
+ 
+ In nova, we should officially deprecate ext3 support in Icehouse's
+ release notes, and change the default to ext4 in Juno.

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

Title:
  creating a large ext3 ephemeral disk filesystem is much slower than
  ext4

Status in OpenStack Compute (Nova):
  New
Status in tripleo - openstack on openstack:
  In Progress

Bug description:
  ext3 is more generally available than ext4, but creating an ext3
  filesystem involves a lot more writing than ext3. The only reason to
  retain ext3 is to retain backward compatibility with very old guest
  OS's or OS's which have chosen not to support ext4 such as SLES.

  A plan should be made to deprecate ext3 support in Nova at some point.
  For TripleO we are not supporting deploying OpenStack itself on older
  OS's like this, thus we should change this setting in our baremetal
  cloud(s) to be ext4.

  In nova, we should officially deprecate ext3 support in Icehouse's
  release notes, and change the default to ext4 in Juno.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1266262/+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 1265740] Re: incorrect return from exception.InvalidInput()

2014-01-05 Thread John Griffith 
don't see any Cinder info here

** Changed in: cinder
   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/1265740

Title:
  incorrect return from exception.InvalidInput()

Status in Cinder:
  Invalid
Status in OpenStack Compute (Nova):
  Incomplete

Bug description:
  when I create instance, and set min_count=-1, like this:

  openstack@openstack-001:~$ curl -i -H 
X-Auth-Token:6db450ec28174970be674af55c644e23 -H 
Content-Type:application/json 
http://127.0.0.1:8774/v2/e7fdc71e46bd4945a57104f3899b1335/servers -d 
'{server:{name:test,flavorRef:42,imageRef:2e33aff9-63b4-497c-9c1b-8fe4ee567cce,min_count:-1}}'
  HTTP/1.1 400 Bad Request
  Content-Length: 110
  Content-Type: application/json; charset=UTF-8
  X-Compute-Request-Id: req-b33a8f37-e4a4-42b3-8488-ca669e80911d
  Date: Fri, 03 Jan 2014 08:04:18 GMT

  {badRequest: {message:
  \u6536\u5230\u65e0\u6548\u7684\u8f93\u5165: min_count must be = 1,
  code: 400}}

  the return message is messy code. I review the code, find the code:
   if min_value is not None:
  if value  min_value:
  msg = _('%(value_name)s must be = %(min_value)d')
  raise exception.InvalidInput(
  reason=(msg % {'value_name': name,
 'min_value': min_value}))

  exception.InvalidInput has no para named reason. the para is message.
  replace message to reason, it is ok.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1265740/+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 1262176] Re: EC2: 'io1' type volume should also return IOPS associated with it

2014-01-05 Thread John Griffith 
Making a compatible version for EBS here isn't a terrible idea, however
i hardly see this as a bug.  This is most definitely a feature request
IMO, and it has almost nothing to do with Cinder.  As per my comments in
the review:

If there's real value in emulating this, then I think this needs to include 
the work to provide the option on create as well as provide it in the get. 
However, there's only ONE option that I'm aware of in EBS today, so this should 
filter out anything that isn't that IO1 type.
In other words, if an admin creates a type with this name, fine... we can 
expose it and allow it to be selected for creation. But we shouldn't expose any 
of the other types and we most certainly should not require this type exist or 
be built by default.

** Changed in: cinder
   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/1262176

Title:
  EC2: 'io1' type volume should also return IOPS associated with it

Status in Cinder:
  Invalid
Status in OpenStack Compute (Nova):
  Confirmed

Bug description:
  This patch https://review.openstack.org/#/c/61041 exposes volume type
  in the EC2 API. Amazon's API documentation says that if the volume
  type is 'io1', that is, if the volume has guaranteed IOPS set for it,
  a 'DescribeVolumes' call should return the IOPS for such volumes. We
  need to add that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1262176/+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 1266334] [NEW] Quota extension is not enabled for bigswitch plugin

2014-01-05 Thread Sumit Naiksatam 
Public bug reported:

Any quota request made to neutron fails with the bigswitch plugin.
Enabling the quota extension will fix this.

** Affects: neutron
 Importance: Medium
 Assignee: Kevin Benton (blak111)
 Status: New


** Tags: bigswitch

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

Title:
  Quota extension is not enabled for bigswitch plugin

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  Any quota request made to neutron fails with the bigswitch plugin.
  Enabling the quota extension will fix this.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1266334/+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 1266344] [NEW] duplicate __init__() in ExtensionResource

2014-01-05 Thread Kun Huang 
Public bug reported:

Let's go in codes directly, to get resources from extension, the child
class[0] has an __init__() to register itself, and the farther class
[1]'s __init__() has already did this. If there are no some specified
variables needed by child class, the child's __init__ could be removed.
In nova/nova/api/openstack/compute/contrib/, nearly all of extensions
class don't have such a duplicate __init__(). Removing the __init__() in
child class could help keeping codes consistent and clean.

[0] 
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/contrib/fixed_ips.py#L88
[1] 
https://github.com/openstack/nova/blob/master/nova/api/openstack/extensions.py#L63

** Affects: nova
 Importance: Undecided
 Assignee: Kun Huang (academicgareth)
 Status: New

** Changed in: nova
 Assignee: (unassigned) = Kun Huang (academicgareth)

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

Title:
  duplicate __init__() in ExtensionResource

Status in OpenStack Compute (Nova):
  New

Bug description:
  Let's go in codes directly, to get resources from extension, the child
  class[0] has an __init__() to register itself, and the farther class
  [1]'s __init__() has already did this. If there are no some specified
  variables needed by child class, the child's __init__ could be
  removed. In nova/nova/api/openstack/compute/contrib/, nearly all of
  extensions class don't have such a duplicate __init__(). Removing the
  __init__() in child class could help keeping codes consistent and
  clean.

  [0] 
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/contrib/fixed_ips.py#L88
  [1] 
https://github.com/openstack/nova/blob/master/nova/api/openstack/extensions.py#L63

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1266344/+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 1266347] [NEW] Metaplugin can not be used with router service-type plugin

2014-01-05 Thread Itsuro Oda 
Public bug reported:

When the metaplugin is selected as the core plugin and a router service-
type plugin is specified at the same time (see below), quantum-server
crashes with the following error.

--- neutron.conf ---
service_plugins = neutron.services.l3_router.l3_router_plugin.L3RouterPlugin
core_plugin = neutron.plugins.metaplugin.meta_neutron_plugin.MetaPluginV2
---

--- error log ---
2013-12-19 16:07:21.282 TRACE neutron   File 
/opt/stack/neutron/neutron/manager.py, line 176, in _load_service_plugins
2013-12-19 16:07:21.282 TRACE neutron plugin_inst.get_plugin_type())
2013-12-19 16:07:21.282 TRACE neutron ValueError: (u'Multiple plugins for 
service %s were configured', 'L3_ROUTER_NAT')
---

Core plugins are going to not support the router extension. The
metaplugin should be able to be used with a router service-type plugin.

** Affects: neutron
 Importance: Undecided
 Assignee: Itsuro Oda (oda-g)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) = Itsuro Oda (oda-g)

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

Title:
  Metaplugin can not be used with router service-type plugin

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  When the metaplugin is selected as the core plugin and a router
  service-type plugin is specified at the same time (see below),
  quantum-server crashes with the following error.

  --- neutron.conf ---
  service_plugins = neutron.services.l3_router.l3_router_plugin.L3RouterPlugin
  core_plugin = neutron.plugins.metaplugin.meta_neutron_plugin.MetaPluginV2
  ---

  --- error log ---
  2013-12-19 16:07:21.282 TRACE neutron   File 
/opt/stack/neutron/neutron/manager.py, line 176, in _load_service_plugins
  2013-12-19 16:07:21.282 TRACE neutron plugin_inst.get_plugin_type())
  2013-12-19 16:07:21.282 TRACE neutron ValueError: (u'Multiple plugins for 
service %s were configured', 'L3_ROUTER_NAT')
  ---

  Core plugins are going to not support the router extension. The
  metaplugin should be able to be used with a router service-type
  plugin.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1266347/+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 1263019] Re: tempest.api.volume.test_volume_transfers.VolumesTransfersTest.test_create_list_delete_volume_transfer failed

2014-01-05 Thread Christopher Yeoh 
*** This bug is a duplicate of bug 1262432 ***
https://bugs.launchpad.net/bugs/1262432

** This bug has been marked a duplicate of bug 1262432
   tempest volume transfer test can race against other tenants

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

Title:
  
tempest.api.volume.test_volume_transfers.VolumesTransfersTest.test_create_list_delete_volume_transfer
  failed

Status in Cinder:
  New
Status in OpenStack Compute (Nova):
  New

Bug description:
  the tempest test failed in gate:
  
http://logs.openstack.org/38/40638/10/check/check-tempest-dsvm-full/8361472/testr_results.html.gz

  message: Invalid volume: Volume status must be available or error, but
  current status is: awaiting-transfer

  but there is  a waiter:
  self.client.wait_for_volume_status(volume['id'], 'available') before
  delete the volume.

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