[Openstack-poc] [Bug 994957] Re: handle all mailmap with name and email address

2012-05-04 Thread Mark McLoughlin
** Changed in: openstack-common
   Status: New => In Progress

** Changed in: openstack-common
   Importance: Undecided => Low

** Changed in: openstack-common
Milestone: None => folsom-1

-- 
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/994957

Title:
  handle all mailmap with name and email address

Status in OpenStack Image Registry and Delivery Service (Glance):
  New
Status in OpenStack Identity (Keystone):
  New
Status in OpenStack Compute (Nova):
  New
Status in openstack-common:
  In Progress

Bug description:
  The parse_mailmap() method handle following format:


  It can't handle following formats:
Foo  Bar 
Foo ZZ  Bar YY 

  All 3 formats are valid mailmap formats, as per this document.
http://man.github.com/git/git-shortlog.html

  Please fix it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/994957/+subscriptions

___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help   : https://help.launchpad.net/ListHelp


[Openstack-poc] [Bug 994957] Re: handle all mailmap with name and email address

2012-05-04 Thread Bhuvaneswaran A
Posted a patch for review in openstack-common project. Once it's merged, i'll 
propagate it to other projects.
  https://review.openstack.org/7150

-- 
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/994957

Title:
  handle all mailmap with name and email address

Status in OpenStack Image Registry and Delivery Service (Glance):
  New
Status in OpenStack Identity (Keystone):
  New
Status in OpenStack Compute (Nova):
  New
Status in openstack-common:
  New

Bug description:
  The parse_mailmap() method handle following format:


  It can't handle following formats:
Foo  Bar 
Foo ZZ  Bar YY 

  All 3 formats are valid mailmap formats, as per this document.
http://man.github.com/git/git-shortlog.html

  Please fix it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/994957/+subscriptions

___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help   : https://help.launchpad.net/ListHelp


[Openstack-poc] [Bug 994957] [NEW] handle all mailmap with name and email address

2012-05-04 Thread Bhuvaneswaran A
Public bug reported:

The parse_mailmap() method handle following format:
  

It can't handle following formats:
  Foo  Bar 
  Foo ZZ  Bar YY 

All 3 formats are valid mailmap formats, as per this document.
  http://man.github.com/git/git-shortlog.html

Please fix it.

** Affects: glance
 Importance: Undecided
 Status: New

** Affects: keystone
 Importance: Undecided
 Status: New

** Affects: nova
 Importance: Undecided
 Status: New

** Affects: openstack-common
 Importance: Undecided
 Assignee: Bhuvaneswaran A (bhuvan)
 Status: New

** Changed in: openstack-common
 Assignee: (unassigned) => Bhuvaneswaran A (bhuvan)

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

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

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

-- 
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/994957

Title:
  handle all mailmap with name and email address

Status in OpenStack Image Registry and Delivery Service (Glance):
  New
Status in OpenStack Identity (Keystone):
  New
Status in OpenStack Compute (Nova):
  New
Status in openstack-common:
  New

Bug description:
  The parse_mailmap() method handle following format:


  It can't handle following formats:
Foo  Bar 
Foo ZZ  Bar YY 

  All 3 formats are valid mailmap formats, as per this document.
http://man.github.com/git/git-shortlog.html

  Please fix it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/994957/+subscriptions

___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help   : https://help.launchpad.net/ListHelp


[Openstack-poc] [Bug 943336] Re: New requirements never get written out

2012-05-04 Thread Jason Kölker
** Changed in: openstack-common
 Assignee: Jason Kölker (jason-koelker) => Monty Taylor (mordred)

-- 
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/943336

Title:
  New requirements never get written out

Status in openstack-common:
  Confirmed

Bug description:
  write_requirements is failing to write out requirements.txt on a new
  virtualenv/checkout. Need to figure out what's going on.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-common/+bug/943336/+subscriptions

___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help   : https://help.launchpad.net/ListHelp


Re: [Openstack-poc] [Bug 943336] Re: New requirements never get written out

2012-05-04 Thread Monty Taylor
Honestly, I think we might want to delete write_requirements()
altogether. I don't think it's beneficial... asign this to me and I'll
get it fixed up.

On 05/04/2012 11:30 AM, Mark McLoughlin wrote:
> Could do with more details here, I'm not sure I follow what the issue is
> 
> ** Changed in: openstack-common
>  Assignee: (unassigned) => Jason Kölker (jason-koelker)
> 
> ** Changed in: openstack-common
>Importance: Undecided => Low
> 
> ** Changed in: openstack-common
> Milestone: None => folsom-1
>

-- 
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/943336

Title:
  New requirements never get written out

Status in openstack-common:
  Confirmed

Bug description:
  write_requirements is failing to write out requirements.txt on a new
  virtualenv/checkout. Need to figure out what's going on.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-common/+bug/943336/+subscriptions

___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help   : https://help.launchpad.net/ListHelp


[Openstack-poc] [Bug 976267] Re: auto generate AUTHORS for packaging

2012-05-04 Thread Bhuvaneswaran A
Mark, nevermind. I got it.

-- 
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/976267

Title:
  auto generate AUTHORS for packaging

Status in OpenStack Dashboard (Horizon):
  New
Status in OpenStack Compute (Nova):
  New
Status in openstack-common:
  Fix Committed
Status in OpenStack Object Storage (Swift):
  New

Bug description:
  As discussed in bug 920757, the check-ins for all projects are gated
  using CLA sign. It's not necessary to enforce an entry in AUTHORS
  file. The file should be auto-generated when we package using "python
  setup.py sdist" command. The .mailmap file, if exists, should be
  honored. This is applicable for all projects, swift, keystone, nova
  and glance.

  Once this is resolved, we could remove the test, test_authors.py that
  check for an entry in AUTHORS file.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/976267/+subscriptions

___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help   : https://help.launchpad.net/ListHelp


[Openstack-poc] [Bug 976267] Re: auto generate AUTHORS for packaging

2012-05-04 Thread Bhuvaneswaran A
Mark, ?? Can you please explain why you set it as "Fix committed" even
though the patch should go in few more projects?

** Changed in: nova
 Assignee: (unassigned) => Bhuvaneswaran A (bhuvan)

-- 
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/976267

Title:
  auto generate AUTHORS for packaging

Status in OpenStack Dashboard (Horizon):
  New
Status in OpenStack Compute (Nova):
  New
Status in openstack-common:
  Fix Committed
Status in OpenStack Object Storage (Swift):
  New

Bug description:
  As discussed in bug 920757, the check-ins for all projects are gated
  using CLA sign. It's not necessary to enforce an entry in AUTHORS
  file. The file should be auto-generated when we package using "python
  setup.py sdist" command. The .mailmap file, if exists, should be
  honored. This is applicable for all projects, swift, keystone, nova
  and glance.

  Once this is resolved, we could remove the test, test_authors.py that
  check for an entry in AUTHORS file.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/976267/+subscriptions

___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help   : https://help.launchpad.net/ListHelp


[Openstack-poc] [Bug 943336] Re: New requirements never get written out

2012-05-04 Thread Mark McLoughlin
Could do with more details here, I'm not sure I follow what the issue is

** Changed in: openstack-common
 Assignee: (unassigned) => Jason Kölker (jason-koelker)

** Changed in: openstack-common
   Importance: Undecided => Low

** Changed in: openstack-common
Milestone: None => folsom-1

-- 
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/943336

Title:
  New requirements never get written out

Status in openstack-common:
  Confirmed

Bug description:
  write_requirements is failing to write out requirements.txt on a new
  virtualenv/checkout. Need to figure out what's going on.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-common/+bug/943336/+subscriptions

___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help   : https://help.launchpad.net/ListHelp


[Openstack-poc] [Bug 976267] Re: auto generate AUTHORS for packaging

2012-05-04 Thread Mark McLoughlin
** Changed in: openstack-common
   Status: In Progress => Fix Committed

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

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

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

-- 
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/976267

Title:
  auto generate AUTHORS for packaging

Status in OpenStack Dashboard (Horizon):
  New
Status in OpenStack Compute (Nova):
  New
Status in openstack-common:
  Fix Committed
Status in OpenStack Object Storage (Swift):
  New

Bug description:
  As discussed in bug 920757, the check-ins for all projects are gated
  using CLA sign. It's not necessary to enforce an entry in AUTHORS
  file. The file should be auto-generated when we package using "python
  setup.py sdist" command. The .mailmap file, if exists, should be
  honored. This is applicable for all projects, swift, keystone, nova
  and glance.

  Once this is resolved, we could remove the test, test_authors.py that
  check for an entry in AUTHORS file.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/976267/+subscriptions

___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help   : https://help.launchpad.net/ListHelp


[Openstack-poc] [Bug 976267] Re: auto generate AUTHORS for packaging

2012-05-04 Thread Bhuvaneswaran A
Mark, the patch for nova is still in review state:
  https://review.openstack.org/#/c/6699/

After this patch, I'm working on patch for few more projects, listed in
#9. Leaving it as "In Progress".

** Changed in: openstack-common
   Status: Fix Committed => In Progress

-- 
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/976267

Title:
  auto generate AUTHORS for packaging

Status in openstack-common:
  In Progress

Bug description:
  As discussed in bug 920757, the check-ins for all projects are gated
  using CLA sign. It's not necessary to enforce an entry in AUTHORS
  file. The file should be auto-generated when we package using "python
  setup.py sdist" command. The .mailmap file, if exists, should be
  honored. This is applicable for all projects, swift, keystone, nova
  and glance.

  Once this is resolved, we could remove the test, test_authors.py that
  check for an entry in AUTHORS file.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-common/+bug/976267/+subscriptions

___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help   : https://help.launchpad.net/ListHelp


[Openstack-poc] [Bug 965563] Re: Usability issue: is_public=yes sets Public: No

2012-05-04 Thread Mark McLoughlin
openstack-common fix: https://review.openstack.org/#/c/5712/

** Changed in: openstack-common
   Status: New => Fix Released

** Changed in: openstack-common
   Importance: Undecided => Medium

** Changed in: openstack-common
 Assignee: (unassigned) => Sean Dague (sdague-b)

** Changed in: openstack-common
Milestone: None => 2012.1

-- 
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/965563

Title:
  Usability issue: is_public=yes sets Public: No

Status in OpenStack Image Registry and Delivery Service (Glance):
  Fix Released
Status in openstack-common:
  Fix Released

Bug description:
  There is a usability with Glance around the use of booleans. The
  is_public metadata for an image is displayed via "glance show" in
  Yes/No terms. i.e.

  Id: 7b1ee878-131b-4c1e-bd14-dc8cb0e48ace
  Public: Yes
  Protected: No
  Name: oneiric-11.10-2
  Status: active
  Size: 10486808576

  However the bool_from_string function (common/utils.py) doesn't define
  'yes' as true.

  This results in the flag is_public=yes actually setting Public: No in
  the image.

  I suggest that 'yes' is added to the list of values considered true.
  There is a proposed change for it here -
  https://review.openstack.org/#change,5712 that would go into common,
  then we could propogate it out to glance proper.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/965563/+subscriptions

___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help   : https://help.launchpad.net/ListHelp


[Openstack-poc] [Bug 967400] Re: iniparser needs absolute import

2012-05-04 Thread Mark McLoughlin
** Changed in: openstack-common
   Status: Fix Committed => Fix Released

** Changed in: openstack-common
   Importance: Undecided => Medium

** Changed in: openstack-common
Milestone: None => 2012.1

-- 
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/967400

Title:
  iniparser needs absolute import

Status in openstack-common:
  Fix Released

Bug description:
  The use of a relative import for 'iniparser' is causing:

  http://paste.openstack.org/show/12224/

  Changing this to:

  from openstack.common import iniparser fixes it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-common/+bug/967400/+subscriptions

___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help   : https://help.launchpad.net/ListHelp


[Openstack-poc] [Bug 967808] Re: Create common __init__

2012-05-04 Thread Mark McLoughlin
** Changed in: openstack-common
   Status: Fix Committed => Fix Released

** Changed in: openstack-common
   Importance: Undecided => Medium

** Changed in: openstack-common
Milestone: None => 2012.1

-- 
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/967808

Title:
  Create common __init__

Status in openstack-common:
  Fix Released

Bug description:
  openstack/common/__init__.py needs to be created when we copy over the
  modules.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-common/+bug/967808/+subscriptions

___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help   : https://help.launchpad.net/ListHelp


[Openstack-poc] [Bug 972859] Re: Fix utils.import_object() when trying to get an instance of a class

2012-05-04 Thread Mark McLoughlin
** Changed in: openstack-common
   Status: Fix Committed => Fix Released

** Changed in: openstack-common
   Importance: Undecided => Medium

** Changed in: openstack-common
Milestone: None => 2012.1

-- 
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/972859

Title:
  Fix utils.import_object() when trying to get an instance of a class

Status in openstack-common:
  Fix Released

Bug description:
  RIght now, utils.import_object('foo') is the same as
  utils.import_class('foo') when 'foo' is the path to a class.  This
  should be fixed so that import_object() returns an instance of that
  class (like how this works in nova.utils).

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-common/+bug/972859/+subscriptions

___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help   : https://help.launchpad.net/ListHelp


[Openstack-poc] [Bug 976267] Re: auto generate AUTHORS for packaging

2012-05-04 Thread Mark McLoughlin
** Changed in: openstack-common
   Status: New => Fix Committed

** Changed in: openstack-common
   Importance: Undecided => Medium

** Changed in: openstack-common
Milestone: None => folsom-1

-- 
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/976267

Title:
  auto generate AUTHORS for packaging

Status in openstack-common:
  Fix Committed

Bug description:
  As discussed in bug 920757, the check-ins for all projects are gated
  using CLA sign. It's not necessary to enforce an entry in AUTHORS
  file. The file should be auto-generated when we package using "python
  setup.py sdist" command. The .mailmap file, if exists, should be
  honored. This is applicable for all projects, swift, keystone, nova
  and glance.

  Once this is resolved, we could remove the test, test_authors.py that
  check for an entry in AUTHORS file.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-common/+bug/976267/+subscriptions

___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help   : https://help.launchpad.net/ListHelp


[Openstack-poc] [Bug 960487] Re: Request deserializer does not pass an empty body

2012-05-04 Thread Mark McLoughlin
Ok, based on Brian Waldon's comment in the review I'm going to close
this

** Changed in: openstack-common
   Status: In Progress => Invalid

** Changed in: openstack-common
   Importance: Undecided => Wishlist

-- 
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/960487

Title:
  Request deserializer does not pass an empty body

Status in openstack-common:
  Invalid

Bug description:
  When a POST is sent via an API call and the body is empty the body is
  lost and not sent along and sending back a general 400 error.

  This should send a body even if it is empty to the method in the route 
specified.
  The common/wsgi.py Request deserializer for the body needs an update so that 
this is possible.

  This will allow the API developer to create a validation message to
  the client with what is invalid in the body of the action.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-common/+bug/960487/+subscriptions

___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help   : https://help.launchpad.net/ListHelp


[Openstack-poc] [Bug 963509] Re: update.py doesn't handle dependencies of configured modules

2012-05-04 Thread Mark McLoughlin
** Changed in: openstack-common
   Status: New => Confirmed

** Changed in: openstack-common
   Importance: Undecided => Wishlist

-- 
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/963509

Title:
  update.py doesn't handle dependencies of configured modules

Status in openstack-common:
  Confirmed

Bug description:
  cfg.py now depends on iniparser.py, but update.py didn't automatically
  copy it. The dependencies can be figured out automatically and
  update.py could be friendlier and help out us poor developers.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-common/+bug/963509/+subscriptions

___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help   : https://help.launchpad.net/ListHelp


[Openstack-poc] [Bug 951197] Re: openstack namespace does not play nicely with checkedout repos

2012-05-04 Thread Mark McLoughlin
Looks like this stills isn't resolved, given the issue Brian Waldon was
seeing: https://review.openstack.org/#/c/6769/

** Changed in: openstack-common
   Status: Incomplete => Confirmed

** Changed in: openstack-common
Milestone: None => folsom-1

** Changed in: openstack-common
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/951197

Title:
  openstack namespace does not play nicely with checkedout repos

Status in openstack-common:
  Confirmed

Bug description:
  Both openstack.common and openstack.nose_plugin declare the
  'openstack' namespace. When one package is installed it breaks pythons
  search path of ./ for modules.  This breaks update.py for example
  which is meant to be run out of the os-common checkout directory. It
  imports cfg from openstack.common, but since it is not installed it
  cannot be found:

  
  site-packages$ ls openstack*
  openstack.nose_plugin-0.5-py2.7-nspkg.pth

  openstack:
  nose_plugin.py  nose_plugin.pyc

  openstack.nose_plugin-0.5-py2.7.egg-info:
  dependency_links.txt  installed-files.txt PKG-INFO  SOURCES.txt
  entry_points.txt  namespace_packages.txt  requires.txt  top_level.txt

  common$ python update.py
  Traceback (most recent call last):
File "update.py", line 64, in 
  from openstack.common import cfg
  ImportError: No module named common

  Since update.py is a "temporary" workaround for incubation we *could*
  hack it to inject ./openstack/common into the openstack namespace, but
  there might be a better way. Need to research.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-common/+bug/951197/+subscriptions

___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help   : https://help.launchpad.net/ListHelp


[Openstack-poc] [Bug 954488] Re: nova/openstack/common/cfg.py: 'nova.api.openstack.contrib.standard_extensions' is non-existant

2012-05-04 Thread Mark McLoughlin
** Changed in: openstack-common
   Status: Fix Committed => Fix Released

** Changed in: openstack-common
   Importance: Undecided => Low

** Changed in: openstack-common
Milestone: None => 2012.1

-- 
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/954488

Title:
  nova/openstack/common/cfg.py:
  'nova.api.openstack.contrib.standard_extensions' is non-existant

Status in OpenStack Compute (Nova):
  Fix Released
Status in openstack-common:
  Fix Released

Bug description:
  nova/openstack/common/cfg.py   refers to
  'nova.api.openstack.contrib.standard_extensions' but this is a non-
  existant path.

  
  nova/openstack/common/cfg.py:
  "
  DEFAULT_EXTENSIONS = [
  'nova.api.openstack.contrib.standard_extensions'
  ]
  "

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/954488/+subscriptions

___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help   : https://help.launchpad.net/ListHelp


[Openstack-poc] [Bug 955308] Re: MultiStrOpt doesn't always accept multiple strings

2012-05-04 Thread Mark McLoughlin
** Changed in: openstack-common
   Status: Fix Committed => Fix Released

** Changed in: openstack-common
Milestone: None => 2012.1

** Changed in: openstack-common
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/955308

Title:
  MultiStrOpt doesn't always accept multiple strings

Status in openstack-common:
  Fix Released

Bug description:
  It appears to work for CLI options but not when using config files.
  Looking at the tests, this appears to be a known bug since the
  assertion in test_conf_file_multistr_values_append has been commented
  out with a FIXME.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-common/+bug/955308/+subscriptions

___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help   : https://help.launchpad.net/ListHelp


[Openstack-poc] [Bug 930270] Re: flagfile interpolation breaks instance_name_template

2012-05-04 Thread Mark McLoughlin
** Changed in: openstack-common
   Status: Fix Committed => Fix Released

** Changed in: openstack-common
Milestone: None => 2012.1

** Changed in: openstack-common
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/930270

Title:
  flagfile interpolation breaks instance_name_template

Status in OpenStack Compute (Nova):
  Fix Released
Status in openstack-common:
  Fix Released

Bug description:
  When --volume_name_template=volume-%08x and
  --instance_name_template=instance-%08x are present in nova.conf,
  ConfigParser attempts to interpolate the '%' strings.  There are meant
  for nova to interpolate.

  2012-02-10 10:54:49,089 DEBUG nova.service [-] osapi_compute_link_prefix : 
None from (pid=22867) wait /opt/stack/nova/nova/service.py:409
  2012-02-10 10:54:49,089 CRITICAL nova [-] '%' must be followed by '%' or '(', 
found: '%08x'
  (nova): TRACE: Traceback (most recent call last):
  (nova): TRACE:   File "/opt/stack/nova/bin/nova-api", line 53, in 
  (nova): TRACE: service.wait()
  (nova): TRACE:   File "/opt/stack/nova/nova/service.py", line 402, in wait
  (nova): TRACE: flag_get = FLAGS.get(flag, None)
  (nova): TRACE:   File "/opt/stack/nova/nova/flags.py", line 73, in get
  (nova): TRACE: value = getattr(self, name)
  (nova): TRACE:   File "/opt/stack/nova/nova/flags.py", line 70, in __getattr__
  (nova): TRACE: return getattr(self._conf, name)
  (nova): TRACE:   File "/opt/stack/nova/nova/openstack/common/cfg.py", line 
784, in __getattr__
  (nova): TRACE: return self._substitute(self._get(name))
  (nova): TRACE:   File "/opt/stack/nova/nova/openstack/common/cfg.py", line 
985, in _get
  (nova): TRACE: return opt._get_from_config_parser(self._cparser, section)
  (nova): TRACE:   File "/opt/stack/nova/nova/openstack/common/cfg.py", line 
433, in _get_from_config_parser
  (nova): TRACE: return cparser.get(section, self.dest)
  (nova): TRACE:   File "/usr/lib/python2.7/ConfigParser.py", line 615, in get
  (nova): TRACE: return self._interpolate(section, option, value, d)
  (nova): TRACE:   File "/usr/lib/python2.7/ConfigParser.py", line 683, in 
_interpolate
  (nova): TRACE: self._interpolate_some(option, L, rawval, section, vars, 1)
  (nova): TRACE:   File "/usr/lib/python2.7/ConfigParser.py", line 724, in 
_interpolate_some
  (nova): TRACE: "'%%' must be followed by '%%' or '(', found: %r" % 
(rest,))
  (nova): TRACE: InterpolationSyntaxError: '%' must be followed by '%' or '(', 
found: '%08x'
  (nova): TRACE:
  stack@356591-essex-k1:/opt/stack/nova$

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/930270/+subscriptions

___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help   : https://help.launchpad.net/ListHelp


[Openstack-poc] [Bug 930625] Re: PEP8 cleanup (openstack-common)

2012-05-04 Thread Mark McLoughlin
** Changed in: openstack-common
Milestone: None => 2012.1

** Changed in: openstack-common
   Status: Fix Committed => Fix Released

** Changed in: openstack-common
   Importance: Undecided => Low

-- 
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/930625

Title:
  PEP8 cleanup (openstack-common)

Status in openstack-common:
  Fix Released

Bug description:
  Remove backslash continuations in openstack-common.
  Fix type checking taboos.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-common/+bug/930625/+subscriptions

___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help   : https://help.launchpad.net/ListHelp


[Openstack-poc] [Bug 947861] Re: cfg: automatically create option groups

2012-05-04 Thread Mark McLoughlin
** Changed in: openstack-common
Milestone: None => folsom-1

** Changed in: openstack-common
   Importance: Undecided => Medium

** Changed in: openstack-common
   Status: Confirmed => Triaged

-- 
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/947861

Title:
  cfg: automatically create option groups

Status in openstack-common:
  Triaged

Bug description:
  If you do e.g.

conf.register_opts(sql_opts, group='sql')

  that should be enough without explicitly defining an OptGroup

  The only real use case for explicitly definining an OptGroup is where
  you want to set some help text/title for the group

  Pointed out by termie here: https://review.openstack.org/4547

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-common/+bug/947861/+subscriptions

___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help   : https://help.launchpad.net/ListHelp


[Openstack-poc] [Bug 627792] Re: Support getting a logger

2012-05-04 Thread Mark McLoughlin
Moving to Opinion, no progress in 18+ months and a blueprint would be
better

** Changed in: openstack-common
   Status: New => Opinion

-- 
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/627792

Title:
  Support getting a logger

Status in openstack-common:
  Opinion

Bug description:
  swift.common.utils.get_logger is a good jumping off point.

  Pass in parameters such as
  * log name ('openstack-foo')
  * method (syslog, rotating file, stderr, etc)
  * log level (DEBUG)

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-common/+bug/627792/+subscriptions

___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help   : https://help.launchpad.net/ListHelp


[Openstack-poc] [Bug 915039] Re: flags.FLAGS( crashes bpython

2012-05-04 Thread Mark McLoughlin
** Changed in: openstack-common
   Status: Fix Committed => Fix Released

** Changed in: openstack-common
Milestone: None => 2012.1

-- 
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/915039

Title:
  flags.FLAGS( crashes bpython

Status in OpenStack Compute (Nova):
  Fix Released
Status in openstack-common:
  Fix Released

Bug description:
  Bpython tries to do some fancy stuff like lookup obj.__name__ and
  check for AttributeError.  The code in common/cfg.py has a special
  getattr that raises a non AttributeError exception so it leads to a
  crash and stack trace in bpython:

  Traceback (most recent call last):
File "/usr/local/share/python/bpython", line 9, in 
  load_entry_point('bpython==0.10.1', 'console_scripts', 'bpython')()
File 
"/usr/local/Cellar/python/2.7.2/lib/python2.7/site-packages/bpython/cli.py", 
line 1756, in main
  banner=banner)
File 
"/usr/local/Cellar/python/2.7.2/lib/python2.7/site-packages/bpython/cli.py", 
line 1658, in curses_wrapper
  return func(stdscr, *args, **kwargs)
File 
"/usr/local/Cellar/python/2.7.2/lib/python2.7/site-packages/bpython/cli.py", 
line 1727, in main_curses
  clirepl.repl()
File 
"/usr/local/Cellar/python/2.7.2/lib/python2.7/site-packages/bpython/cli.py", 
line 1015, in repl
  inp = self.get_line()
File 
"/usr/local/Cellar/python/2.7.2/lib/python2.7/site-packages/bpython/cli.py", 
line 600, in get_line
  if self.p_key(key) is None:
File 
"/usr/local/Cellar/python/2.7.2/lib/python2.7/site-packages/bpython/cli.py", 
line 911, in p_key
  self.addstr(key)
File 
"/usr/local/Cellar/python/2.7.2/lib/python2.7/site-packages/bpython/cli.py", 
line 290, in addstr
  self.complete()
File 
"/usr/local/Cellar/python/2.7.2/lib/python2.7/site-packages/bpython/cli.py", 
line 383, in complete
  self.list_win_visible = repl.Repl.complete(self, tab)
File 
"/usr/local/Cellar/python/2.7.2/lib/python2.7/site-packages/bpython/repl.py", 
line 540, in complete
  if not self.get_args():
File 
"/usr/local/Cellar/python/2.7.2/lib/python2.7/site-packages/bpython/repl.py", 
line 511, in get_args
  self.argspec = inspection.getargspec(func, f)
File 
"/usr/local/Cellar/python/2.7.2/lib/python2.7/site-packages/bpython/inspection.py",
 line 229, in getargspec
  func_name = getattr(f, '__name__', None)
File "nova/flags.py", line 114, in __getattr__
  return getattr(self._conf, name)
File "nova/common/cfg.py", line 777, in __getattr__
  return self._substitute(self._get(name))
File "nova/common/cfg.py", line 930, in _get
  info = self._get_opt_info(name, group)
File "nova/common/cfg.py", line 1010, in _get_opt_info
  raise NoSuchOptError(opt_name, group)
  nova.common.cfg.NoSuchOptError: no such option: __name__

  To test, you do:
  bpython
  then at prompt:
  >>> from nova import flags
  >>> flags.FLAGS(

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/915039/+subscriptions

___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help   : https://help.launchpad.net/ListHelp


[Openstack-poc] [Bug 925775] Re: utils.import_object sometimes masks the failed import

2012-05-04 Thread Mark McLoughlin
Think this is fixed by: https://review.openstack.org/#/c/6906/

** Changed in: openstack-common
Milestone: None => folsom-1

** Changed in: openstack-common
 Assignee: (unassigned) => Russell Bryant (russellb)

** Changed in: openstack-common
   Importance: Undecided => Medium

** Changed in: openstack-common
   Status: Confirmed => Fix Committed

-- 
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/925775

Title:
  utils.import_object sometimes masks the failed import

Status in openstack-common:
  Fix Committed

Bug description:
  146 def import_class(import_str):
  147 """Returns a class from a string including module and class"""
  148 mod_str, _sep, class_str = import_str.rpartition('.')
  149 try:
  150 __import__(mod_str)
  151 return getattr(sys.modules[mod_str], class_str)
  152 except (ImportError, ValueError, AttributeError):
  153 raise exception.NotFound('Class %s cannot be found' % class_str)

  From time to time we are seeing the exception raised without the
  class_str being filled in making it fun to track down what is not
  installed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-common/+bug/925775/+subscriptions

___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help   : https://help.launchpad.net/ListHelp


[Openstack-poc] [Bug 927650] Re: cfg: unneeded multiple inheritance

2012-05-04 Thread Mark McLoughlin
** Changed in: openstack-common
Milestone: None => 2012.1

** Changed in: openstack-common
   Importance: Undecided => Low

** Changed in: openstack-common
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/927650

Title:
  cfg: unneeded multiple inheritance

Status in openstack-common:
  Fix Released

Bug description:
  From Monsyne Dragon in https://review.openstack.org/3729

File nova/openstack/common/cfg.py
Line 696: class ConfigOpts(collections.Mapping, object):
I don't think we really need to multiply inherit from 'object' here. 
esp. since collections.Mapping already inherits from object.

While this doesn't affect anything atm, this kind of diamond inheritance 
may lead to some rather non-intuitive behavior if  
someone subclasses ConfigOpts in the future

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-common/+bug/927650/+subscriptions

___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help   : https://help.launchpad.net/ListHelp


[Openstack-poc] [Bug 946573] Re: 404 handler for doc sites

2012-05-04 Thread Mark McLoughlin
** Project changed: openstack-common => openstack-ci

-- 
You received this bug notification because you are a member of OpenStack
Common Drivers, which is the registrant for openstack-common.
https://bugs.launchpad.net/bugs/946573

Title:
  404 handler for doc sites

Status in OpenStack Core Infrastructure:
  New

Bug description:
  Since our pages will evolve, it would be good to have a catch-all
  (perhaps per project) 404 handler on pages like:

 http://keystone.openstack.org/page_not_found

  or

 http://nova.openstack.org/secret_stuff

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-ci/+bug/946573/+subscriptions

___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help   : https://help.launchpad.net/ListHelp


Re: [Openstack-poc] 3rd Party APIs

2012-05-04 Thread Thierry Carrez
Jay Pipes wrote:
>> Openstack-common, openstack-ci, or things we gate the core product on
>> (devstack, tempest) should never be part of OpenStack Core (or ever be
>> incubated to become core). However they are necessary for us to produce
>> OpenStack core, and require our collective attention and support. So
>> they need to be blessed in some kind of "official" category meaning they
>> are an central part of "OpenStack" as a development community. Maybe
>> "OpenStack Companion project"...
> 
> I don't necessarily view openstack-ci and openstack-common in the same
> vein. I think openstack-common actually should be part of core since it
> is an important dependency for so many of the core projects (and
> becoming more so...). Openstack-ci, tempest and devstack are also
> critical pieces, but they are support projects, not necessarily
> dependencies. So I would categorize them as "OpenStack Supporting
> Projects" or similar.

Agreed, but openstack-common probably needs to become a formal library
before it can be part of "Core"... As long as it's an area to stage
common stuff waiting to be copied into real projects, it's more a
"supporting project".

>> Another category could be necessary to describe external
>> projects/plug-ins that are continuously tested with OpenStack Core as
>> part of our integration testing and for which we therefore have a pretty
>> good idea of how well they work with OpenStack. Choosing the right term
>> is a bit more tricky here since most names are a bit overloaded. Maybe
>> "OpenStack recommended project/plugin"...
> 
> The term "recommended" comes with a lot of baggage :) I don't want
> plugins to be recommended or suggested -- at least by the community;
> companies should feel free to recommend or suggest whatever they feel is
> best for their distro or deployment. I just want a category called
> "OpenStack Extensions" (or Plugins, depending on what the
> semantics-du-jour happen to be.

It's certainly better :) So test-integrated projects/plugins would be
called "OpenStack extensions" while stuff supposed to be compatible with
openstack (but not tested by us) would be called...
OpenStack-supposedly-compatible ecosystem add-ons ?

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack

___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help   : https://help.launchpad.net/ListHelp


[Openstack-poc] Fwd: 3rd Party APIs

2012-05-04 Thread Thierry Carrez
FYI. Here is a message that was sent to the list but was refused as
non-member post. I think it brings some perspective on how the ecosystem
is organizing about 3rd party APIs support, so I forward it on this thread.

 Message original 
Sujet:  3rd Party APIs
Date :  Thu, 3 May 2012 15:57:50 +0200
De :jean-pierre.lai...@bull.net
Pour :  openstack-poc@lists.launchpad.net
Copie à :   ijm...@hotmail.com


Dear all,

We would like to present some insight that we have gained, through work
that performed in our project, for discusion on the table of this highly
interesting thread.

In CompatibleOne, we took the decision to interoperate with OpenStack
through a proxy and more precisely, in our case, an OCCI component that
we call a PROCCI.

We are using the Nova API, and only that API.

We remap it for use through this OCCI component to satisfy the
provisioning needs of our open source cloud broker.

This technique allows us to interoperate with any other platform in much
the same way. And we could easily encapsulate, and consequently be
compatible with standards such as OCCI Infrastructure. Others such as
CIMI or CDMI could easily be adopted as and when they become publicly
available.

Whilst contributing to OCCI and more than happy to be working with
OpenStack, we are looking for the assurance that it is possible to be
able to perform  complete and fully automated provisioning through the
native NOVA APIs.

We are looking for well documented and stable API on which our system
can be built.

For the rest we can easily manage as we have already done with Cactus,
Diablo and now Essex.
If the transition from release to release could be less painful it would
really save valuable time ;)

We would also appreciate the idea to have simple test kit to self assess
that our OpenStack PROCCI works properly and we would be willing to
consacrate time to participate in such an effort.

HTH

Jean-Pierre Laisne and Jamie Marshall
CompatibleOne coordinator and CTO
www.compatibleone.org 

___
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help   : https://help.launchpad.net/ListHelp