Re: [Openstack-poc] User Committee appointee

2012-09-11 Thread Mark McLoughlin 
On Tue, 2012-09-11 at 06:49 -0500, Jonathan Bryce wrote:
> On Sep 11, 2012, at 3:41 AM, Mark McLoughlin wrote:
> 
> > On Tue, 2012-09-11 at 10:28 +0200, Thierry Carrez wrote:
> >> Jonathan Bryce wrote:

> >>> I would like to start by nominating Ryan Lane from Wikimedia. I think 
> >>> Ryan has done a great job of evangelizing OpenStack and also being a good 
> >>> voice for users among the technical community.
> >>> 
> >>> Anyone else is welcome to nominate alternatives.
> >> 
> >> IMHO our ideal appointed member would be someone that is a user of
> >> OpenStack but also knows our development processes and has directly
> >> contributed to the project at some point. That way, while still being a
> >> "user", he can efficiently bring a perspective on what the developers
> >> can and cannot do.
> >> 
> >> Ryan is definitely a very good option here. An alternative could be
> >> someone from Rackspace/HP Ops side that would also be involved a bit in
> >> development, but I don't know them well enough to pick.
> > 
> > I think Ryan is a good choice too.
> > 
> > However, I wonder whether we should aim to choose someone from the
> > Technical Committee itself - i.e. that whoever the TC appoints would
> > actually be a representative of the TC. Given that Tim Bell is a
> > Foundation Board member, it probably makes sense.
> > 
> > Look outside the TC if there's no-one on the TC willing to commit to the
> > role, perhaps?
> 
> TIm Bell's board membership is coincidental to his user committee
> appointment. The user committee members are meant to be
> representatives of users, not the board or the TC. The companies and
> the ATC are pretty strongly represented within the governance
> structure already, and the user committee is meant to be a place for
> users and deployers who are not as directly represented.

Understood. I was thinking of the Board/TC representatives on the UC as
folks who would act as a bridge between the bodies - e.g. one easy way
for the TC to talk to the UC.

I totally agree that we don't want the UC filled with folks from the
Board or TC.

> I think Ryan fits the bill pretty well while also having a strong
> connection back to the development community. While I'm sure TC
> members would do fine in the role, I'm not sure any of the existing or
> potential members would do a *better* job than Ryan.

Absolutely not questioning Ryan's suitability for the the UC. And he's a
great candidate to help bootstrap it too.

Maybe we just discuss whether anyone is interested in representing the
TC on the UC after the election?

Cheers,
Mark.


___
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] User Committee appointee

2012-09-11 Thread Mark McLoughlin 
On Tue, 2012-09-11 at 10:28 +0200, Thierry Carrez wrote:
> Added markmc and john-griffith as they recently joined the PPB/TC.

Thanks :)

> (Note: We'll refactor this list as soon as the elections are completed
> but it will do until then)

Looking forward to that - it'd be nice if we could allow non-TC members
to subscribe to the list so folks don't have to check the archives to
follow along. Perhaps moderate non-TC members.

> Jonathan Bryce wrote:
> > Last Friday, the Foundation Board of Directors appointed Tim Bell as a 
> > member of the User Committee. According to the Bylaws, the Technical 
> > Committee also needs to appoint someone to the User Committee. Those two 
> > initial appointees will then be able to bootstrap the User Committee and 
> > grow it further.
> 
> Should we wait for the result of the ongoing elections, or is the
> current PPB enough of the "Technical Committee" to be able to appoint
> someone as far as the bylaws are concerned ?

Bylaws aside, I think it probably makes sense. That way the User
Committee is fully part of the new Foundation setup rather than
appointed, in part, by the "old guard".

But that does mean waiting another 2 weeks, which gives whoever we
appoint less time to prepare for the summit.

> > Would you all like to meet briefly tomorrow during our regular time to 
> > discuss this and appoint someone? Alternately, we could handle it over 
> > email.
> 
> Email is OK. At this point it's mostly about brainstorming options, and
> I'm pretty sure we can reach consensus over email.
> 
> > I would like to start by nominating Ryan Lane from Wikimedia. I think Ryan 
> > has done a great job of evangelizing OpenStack and also being a good voice 
> > for users among the technical community.
> > 
> > Anyone else is welcome to nominate alternatives.
> 
> IMHO our ideal appointed member would be someone that is a user of
> OpenStack but also knows our development processes and has directly
> contributed to the project at some point. That way, while still being a
> "user", he can efficiently bring a perspective on what the developers
> can and cannot do.
> 
> Ryan is definitely a very good option here. An alternative could be
> someone from Rackspace/HP Ops side that would also be involved a bit in
> development, but I don't know them well enough to pick.

I think Ryan is a good choice too.

However, I wonder whether we should aim to choose someone from the
Technical Committee itself - i.e. that whoever the TC appoints would
actually be a representative of the TC. Given that Tim Bell is a
Foundation Board member, it probably makes sense.

Look outside the TC if there's no-one on the TC willing to commit to the
role, perhaps?

Cheers,
Mark.


___
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] [OpenStack Foundation] Technical Committee: reserved seats for PTLs (or not)

2012-06-20 Thread Mark McLoughlin 
On Wed, 2012-06-20 at 12:18 +0200, Thierry Carrez wrote:
[..]
> So I think the key question is whether the TC should be considered "the
> college of the PTLs + a number of extra elected people", or "whoever the
> technical contributors elect for the job, who may or may not also be PTLs".
[..]

Nice summary. Interested folks can also read the debate at last night's
PPB meeting:

  
http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-06-19-20.00.log.html

I completely buy your argument that all seats should be elected. And I
also expect that most PTLs would be elected.

Put it this way - with the "all seats are elected" model, a voting
contributor gets to weigh up the likely contribution to the committee of
a given PTL versus other non-PTL candidates. I think that's healthy.


Related, I think the committee should be making more of an effort to
encourage "rough consensus" in the community on the matters under their
consideration. IMHO, committee members should be voting on "is there a
workable rough consensus on this matter?" rather than voting based
purely on their own personal opinion.

If that was the case, any PTL who was constructively engaging in a
debate and helping to reach a consensus would have no fear of being
ignored.

Cheers,
Mark.


___
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-08 Thread Mark McLoughlin 
Hey,

I just realised there's a thread on the openstack-poc list about how
OpenStack should view implementations of APIs other than the OpenStack
API:

  https://lists.launchpad.net/openstack-poc/msg00448.html

(PPB members - please note that other folks can't subscribe to the POC
list. If you want an open discussion on something, the openstack-poc
list isn't the place for it)


tl;dr - rather than actively discouraging folks from contributing native
API implementations, encourage them to resolve the current difficulties
with the EC2 API and their work as a test case for feature/subsystem
branch development process.


The discussion is fairly complex and seems to degenerate into an overly
general "what is and is not core" discussion. There also seems to be a
sense of urgency around finding a final solution here, which I don't
fully understand. The truth is we don't know the answer. We just need to
have some rough idea of what we're trying to achieve and figure out the
thing we want to try next. We'll likely have to try a bunch of stuff
before finding one that works.

What I'd like to see us get to is:

  Deep overlap between the OpenStack developer community and the
  community of folks drafting whatever IaaS standard(s) wind up being
  dominant.

  e.g. prominent, active Nova developers developers contributing to the 
  CIMI or OCCI standards and bringing the needs of OpenStack to the 
  standard and bringing ideas from the standards process to OpenStack.

This isn't a question of asking existing OpenStack developers to join
these standards bodies. It's about enabling members of those standards
bodies to become as much a part of OpenStack as any other developer.

How to do that? Encourage members the various standards communities to
actively contribute an implementation of their standard to OpenStack
and, more importantly, stick around to become an ongoing active member
of the OpenStack developer community.

If this worked out, OpenStack would gain new developers, new ideas and
would be seen as the best place to do new work around IaaS APIs.


AFAICT nova-core has two major concerns with the EC2 API - 1) currently
having to make a change once in the OpenStack API and again in the EC2
API and 2) the EC2 isn't maintenance isn't sufficiently active.

I think a lot of the urgency around this discussion is wanting to avoid
exacerbating the situation by adding another API. To me, the answer is
fairly simple. We cannot accept a new API until these concerns are
addressed:

  1) The amount of duplication between the OpenStack, EC2 and any 
 proposed API needs to be significantly reduced

  2) The developers of any proposed new API need to demonstrate a 
 commitment (through their work) to sticking around as active 
 OpenStack developers maintaining the API (perhaps as a subsystem 
 tree)

That's a high bar, and I expect only seriously committed contributors
would meet it. In the meantime, those contributors can work on their
APIs as feature branches and encourage others to give feedback.


Two alternatives to the above are on the table. Firstly, implementing
these APIs as deltacloud-like proxy servers and blessing these as
"official" OpenStack products. IMHO, proxies are architecturally less
than ideal. Perhaps with enough engineering effort (including OpenStack
API additions) we can get to where they are almost on-par with a native
API, but I'm sceptical.

The other option is to support these APIs with external plugins. For us
to get there, we need a stable library-like API that these plugins can
depend on. It's potentially an ideal solution, but I think we've a long
way to get there. A stepping stone is the re-factoring to reduce
duplication between APIs.


Cheers,
Mark.


___
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] openstack-common bug spam

2012-05-08 Thread Mark McLoughlin 
Hey,

I see this list gets a bunch of bug spam because the POC team is listed
as a driver for the openstack-common library:

  https://launchpad.net/~openstack-common-drivers/+members#active

The doesn't make much sense to me. Anyone have an objection to me
removing the POC team?

Cheers,
Mark.


___
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 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 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 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

[Openstack-poc] [Bug 983734] Re: Keystone fails badly if you miss one option

2012-04-25 Thread Mark McLoughlin 
I'd like the defaults to be configurable by distributors, distutils,
etc. and this is a common pattern with autoconf based projects.

What I don't accept, though, is that we should require users to specify
config options just because we can't figure out a mechanism to get sane
defaults right out of the box. And requiring users to re-write their
config files when they update to new versions is not a workable
mechanism.

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

Title:
  Keystone fails badly if you miss one option

Status in OpenStack Identity (Keystone):
  Confirmed
Status in openstack-common:
  Invalid

Bug description:
  If you misspell or forget one option in keystone.conf (like
  template_file  for TemplatedCatalog backend), Keystone will fail with
  misguiding critical failure (in my case, "TypeError: coercing to
  Unicode: need string or buffer, NoneType found").

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/983734/+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 983734] Re: Keystone fails badly if you miss one option

2012-04-24 Thread Mark McLoughlin 
./etc/default_catalog.template is not a good default for template_file,
I agree. But /etc/keystone/catalog.template or similar would be a fine
default to include in the code. The tests would override the default

As for error messages - I completely agree we should have good error
handling like "default_catalog.template" not found

None of this implies that we shouldn't have good defaults for options
and instead require users to specify values for them

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

Title:
  Keystone fails badly if you miss one option

Status in OpenStack Identity (Keystone):
  Confirmed
Status in openstack-common:
  Invalid

Bug description:
  If you misspell or forget one option in keystone.conf (like
  template_file  for TemplatedCatalog backend), Keystone will fail with
  misguiding critical failure (in my case, "TypeError: coercing to
  Unicode: need string or buffer, NoneType found").

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/983734/+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 983734] Re: Keystone fails badly if you miss one option

2012-04-24 Thread Mark McLoughlin 
The problem here is really that keystone puts required default values in
the config file and not in the code

My cfg re-factoring patches fixed this e.g. in
https://review.openstack.org/#/c/4551/10/keystone/catalog/backends/templated.py
I register a default in the code for template_file. Since we're likely
not going ahead with those patches, I can pull out the defaults cleanups
separately

If the service can't start without a value for the config, then the
option is essentially required. The user must specify a value. I don't
think any of keystone options fall into that category, but I've added a
blueprint for required options in cfg: https://blueprints.launchpad.net
/openstack-common/+spec/cfg-required-options

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

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

Title:
  Keystone fails badly if you miss one option

Status in OpenStack Identity (Keystone):
  Confirmed
Status in openstack-common:
  Invalid

Bug description:
  If you misspell or forget one option in keystone.conf (like
  template_file  for TemplatedCatalog backend), Keystone will fail with
  misguiding critical failure (in my case, "TypeError: coercing to
  Unicode: need string or buffer, NoneType found").

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/983734/+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 983734] Re: Keystone fails badly if you miss one option

2012-04-24 Thread Mark McLoughlin 
** Also affects: openstack-common
   Importance: Undecided
   Status: New

** Changed in: openstack-common
   Status: New => 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/983734

Title:
  Keystone fails badly if you miss one option

Status in OpenStack Identity (Keystone):
  Confirmed
Status in openstack-common:
  In Progress

Bug description:
  If you misspell or forget one option in keystone.conf (like
  template_file  for TemplatedCatalog backend), Keystone will fail with
  misguiding critical failure (in my case, "TypeError: coercing to
  Unicode: need string or buffer, NoneType found").

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/983734/+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-04-04 Thread Mark McLoughlin 
** 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/960487

Title:
  Request deserializer does not pass an empty body

Status in openstack-common:
  In Progress

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 950335] Re: Allow fetching the default value of an opt without interpolation

2012-03-09 Thread Mark McLoughlin 
It turns out the issue wasn't interpolation at all

http://review.openstack.org/5142

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

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

Title:
  Allow fetching the default value of an opt without interpolation

Status in openstack-common:
  Invalid

Bug description:
  The nova/tools/conf/generate_sample.sh script creates a nice sample
  nova config file with all the options listed with their help docs and
  default

  However, the defaults values are interpolated - cfg should have an API
  for getting these values before interpolation

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-common/+bug/950335/+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 950335] [NEW] Allow fetching the default value of an opt without interpolation

2012-03-08 Thread Mark McLoughlin 
Public bug reported:

The nova/tools/conf/generate_sample.sh script creates a nice sample nova
config file with all the options listed with their help docs and default

However, the defaults values are interpolated - cfg should have an API
for getting these values before interpolation

** Affects: openstack-common
 Importance: Undecided
 Assignee: Mark McLoughlin (markmc)
 Status: Confirmed

** Changed in: openstack-common
 Assignee: (unassigned) => Mark McLoughlin (markmc)

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

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

Title:
  Allow fetching the default value of an opt without interpolation

Status in openstack-common:
  Confirmed

Bug description:
  The nova/tools/conf/generate_sample.sh script creates a nice sample
  nova config file with all the options listed with their help docs and
  default

  However, the defaults values are interpolated - cfg should have an API
  for getting these values before interpolation

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-common/+bug/950335/+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-03-06 Thread Mark McLoughlin 
** Tags added: cfg

-- 
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 Committed

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 927650] Re: cfg: unneeded multiple inheritance

2012-03-06 Thread Mark McLoughlin 
** Tags added: cfg

-- 
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 Committed

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 930270] Re: flagfile interpolation breaks instance_name_template

2012-03-06 Thread Mark McLoughlin 
** Tags added: cfg

-- 
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 Committed

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 947718] Re: [DEFAULT] group name in config file must be uppercase

2012-03-06 Thread Mark McLoughlin 
I would have changed the status to WontFix, but I don't have perms for
that

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

Title:
  [DEFAULT] group name in config file must be uppercase

Status in openstack-common:
  Invalid

Bug description:
  As handled by openstack.common.cfg the default group header
  ([DEFAULT]) is only recognized in uppercase.  [default] is not
  recognized as a valid group header for global config options.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-common/+bug/947718/+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 947718] Re: [DEFAULT] group name in config file must be uppercase

2012-03-06 Thread Mark McLoughlin 
Yeah, that's the behaviour of python's ConfigParser

See ConfigParser.py:

  DEFAULTSECT = "DEFAULT"

** Tags added: cfg

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

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

Title:
  [DEFAULT] group name in config file must be uppercase

Status in openstack-common:
  Invalid

Bug description:
  As handled by openstack.common.cfg the default group header
  ([DEFAULT]) is only recognized in uppercase.  [default] is not
  recognized as a valid group header for global config options.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-common/+bug/947718/+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-03-06 Thread Mark McLoughlin 
** Changed in: openstack-common
   Status: New => Confirmed

** Changed in: openstack-common
 Assignee: (unassigned) => Mark McLoughlin (markmc)

-- 
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:
  Confirmed

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 947861] [NEW] cfg: automatically create option groups

2012-03-06 Thread Mark McLoughlin 
Public bug reported:

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

** Affects: openstack-common
 Importance: Undecided
 Assignee: Mark McLoughlin (markmc)
 Status: Confirmed


** Tags: cfg

-- 
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:
  Confirmed

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 930270] Re: flagfile interpolation breaks instance_name_tempalte

2012-02-10 Thread Mark McLoughlin 
** Also affects: openstack-common
   Importance: Undecided
   Status: New

** Changed in: nova
 Assignee: (unassigned) => Mark McLoughlin (markmc)

** Changed in: openstack-common
 Assignee: (unassigned) => Mark McLoughlin (markmc)

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

** Changed in: openstack-common
   Status: New => 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/930270

Title:
  flagfile interpolation breaks instance_name_tempalte

Status in OpenStack Compute (Nova):
  In Progress
Status in openstack-common:
  In Progress

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 927650] [NEW] cfg: unneeded multiple inheritance

2012-02-06 Thread Mark McLoughlin 
Public bug reported:

>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

** Affects: openstack-common
 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/927650

Title:
  cfg: unneeded multiple inheritance

Status in openstack-common:
  New

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