Re: [openstack-dev] [infra][project-config][oslo.messaging] Pre-driver requirements split-up initiative

2015-02-06 Thread Donald Stufft

 On Feb 6, 2015, at 9:00 AM, Jeremy Stanley fu...@yuggoth.org wrote:
 
 On 2015-02-06 14:37:08 +0200 (+0200), Denis Makogon wrote:
 As part of oslo.messaging initiative to split up requirements into
 certain list of per messaging driver dependencies
 [...]
 
 I'm curious what the end goal is here... when someone does `pip
 install oslo.messaging` what do you/they expect to get installed?
 Your run-parts style requirements.d plan is sort of
 counter-intuitive to me in that I would expect it to contain
 number-prefixed sublists of requirements which should be processed
 collectively in an alphanumeric sort order, but I get the impression
 this is not the goal of the mechanism (I'll be somewhat relieved if
 you tell me I'm mistaken in that regard).
 
 Taking into account suggestion from Monty Taylor i’m bringing this
 discussion to much wider audience. And the question is: aren’t we
 doing something complex or are there any less complex ways to
 accomplish the initial idea of splitting requirements?
 
 As for taking this to a wider audience we (OpenStack) are already
 venturing into special snowflake territory with PBR, however
 requirements.txt is a convention used at least somewhat outside of
 OpenStack-related Python projects. It might make sense to get input
 from the broader Python packaging community on something like this
 before we end up alienating ourselves from them entirely.

I’m not sure what exactly is trying to be achieved here, but I still assert
that requirements.txt is the wrong place for pbr to be looking and it should
instead look for dependencies specified inside of a setup.cfg.

More on topic, I'm not sure what inner dependencies are, but if what you're
looking for is optional dependencies that only are needed in specific situation
then you probably want extras, defined like:

setup(
extras_require={
somename: [
dep1,
dep2,
],
},
)

Then if you do ``pip install myproject[somename]`` it'll include dep1 and dep2
in the list of dependencies, you can also depend on this in other projects
like:

setup(
install_requires=[myproject[somename]=1.0],
)

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [infra][project-config][oslo.messaging] Pre-driver requirements split-up initiative

2015-02-06 Thread Doug Hellmann


On Fri, Feb 6, 2015, at 09:56 AM, Denis Makogon wrote:
 On Fri, Feb 6, 2015 at 4:16 PM, Donald Stufft don...@stufft.io wrote:
 
 
   On Feb 6, 2015, at 9:00 AM, Jeremy Stanley fu...@yuggoth.org wrote:
  
   On 2015-02-06 14:37:08 +0200 (+0200), Denis Makogon wrote:
   As part of oslo.messaging initiative to split up requirements into
   certain list of per messaging driver dependencies
   [...]
  
   I'm curious what the end goal is here... when someone does `pip
   install oslo.messaging` what do you/they expect to get installed?
   Your run-parts style requirements.d plan is sort of
   counter-intuitive to me in that I would expect it to contain
   number-prefixed sublists of requirements which should be processed
   collectively in an alphanumeric sort order, but I get the impression
   this is not the goal of the mechanism (I'll be somewhat relieved if
   you tell me I'm mistaken in that regard).
  
   Taking into account suggestion from Monty Taylor i’m bringing this
   discussion to much wider audience. And the question is: aren’t we
   doing something complex or are there any less complex ways to
   accomplish the initial idea of splitting requirements?
  
   As for taking this to a wider audience we (OpenStack) are already
   venturing into special snowflake territory with PBR, however
   requirements.txt is a convention used at least somewhat outside of
   OpenStack-related Python projects. It might make sense to get input
   from the broader Python packaging community on something like this
   before we end up alienating ourselves from them entirely.
 
  I’m not sure what exactly is trying to be achieved here, but I still assert
  that requirements.txt is the wrong place for pbr to be looking and it
  should
  instead look for dependencies specified inside of a setup.cfg.
 
  Sorry, i had to explain what i meant by saying 'inner dependency'. Let me
 be more clear at this step to avoid misunderstanding in terminology.
 Inner  dependency - is a redirection from requirements.txt to another
 file
 that contains additional dependencies (-r another_deps.txt)
 
  More on topic, I'm not sure what inner dependencies are, but if what
  you're
  looking for is optional dependencies that only are needed in specific
  situation
  then you probably want extras, defined like:
 
  setup(
  extras_require={
  somename: [
  dep1,
  dep2,
  ],
  },
  )
 
 
 That might be the case, but since we want to split up requirements into
 per-driver dependecies, it would require to check if setup.cfg can handle
 use of inner dependencies. for example:
 
 setup(
 extras_require={
 somename: [
 -r another_file_with_deps.txt,
 ],
 },
 )

Let's see if we can make pbr add the extras_require values. We can then
either specify the requirements explicitly in setup.cfg, or use a naming
convention for separate requirements files. Either way, we shouldn't
need setuptools to understand that we are managing the list of
requirements in files.

 
 
  Then if you do ``pip install myproject[somename]`` it'll include dep1 and
  dep2
  in the list of dependencies, you can also depend on this in other projects
  like:
 
  setup(
  install_requires=[myproject[somename]=1.0],
  )
 
 
 That's i've been looking for, so, for future installations it'll be very
 useful if cloud deployer knows which AMQP service will be used,
 then he'd be able to install only that type of oslo.messaging that he
 wants
 i.e.
 
 project/requirements.txt:
 ...
 oslo.messaging[amqp1]=${version}
 
 ...
 
 Really great input, thanks Donald. Appreciate it.
 
 ---
  Donald Stufft
  PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
 
 
  __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 Kind regards,
 Denis M.
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [infra][project-config][oslo.messaging] Pre-driver requirements split-up initiative

2015-02-06 Thread Doug Hellmann


On Fri, Feb 6, 2015, at 07:37 AM, Denis Makogon wrote:
 Hello to All.
 
 
 As part of oslo.messaging initiative to split up requirements into
 certain
 list of per messaging driver dependencies
 https://review.openstack.org/#/c/83150/
 
 it was figured that we need to find a way to use pip inner dependencies
 and
 we were able to do that, short info our solution and how it works:
 
 
 
- This is how regular requirements.txt looks:
 
 dep1
 
 …
 
 dep n
 
 
- This is how looks requirements.txt with inner dependencies:
 
 dep1
 
 -r somefolder/another-requirements.txt
 
 -r completelyanotherfolder/another-requirements.txt
 
 …
 
 dep n
 
 That’s what we’ve did for oslo.messaging. But we’ve faced with problem
 that
 was defined as openstack-infra/project-config
 
 tool issue, this tool called project-requirements-change
 https://github.com/openstack-infra/project-config/blob/master/jenkins/scripts/project-requirements-change.py
 .As you can see it’s not able to handle inner dependencies in any
 
 of requirements.txt files, as you can see this tool expects to parse only
 explicit set of requirements (see regular requirements.txt definition
 above).
 
 So, i decided to fix that tool to make it able to look over inner
 dependencies, and here’s https://review.openstack.org/#/c/153227/ what
 i
 have for yesterday,
 
 Taking into account suggestion from Monty Taylor i’m bringing this
 discussion to much wider audience.
 
 And the question is: aren’t we doing something complex or are there any
 less complex ways to
 
 accomplish the initial idea of splitting requirements?

After re-reading this message, and discussing it with a few folks in the
infra channel on IRC, I'm a little concerned that we don't have enough
background to fully understand the problem and proposed solution. bnemec
pointed out that the discussion happened before we had the spec process,
but now that we do have that process I think the best next step is to
have a spec written in oslo-specs describing the problem we're trying to
solve and the approaches that were discussed. This may really just be
summarizing the existing discussions, but let's get all of that
information into a single document before we go any further.

Doug

 
 
 Kind regards,
 
 Denis M.
 IRC: denis_makogon at Freenode
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [infra][project-config][oslo.messaging] Pre-driver requirements split-up initiative

2015-02-06 Thread Davanum Srinivas
Sounds good to me Doug. +1 for a spec since this will affect every project.

-- dims

On Fri, Feb 6, 2015 at 11:12 AM, Doug Hellmann d...@doughellmann.com wrote:


 On Fri, Feb 6, 2015, at 07:37 AM, Denis Makogon wrote:
 Hello to All.


 As part of oslo.messaging initiative to split up requirements into
 certain
 list of per messaging driver dependencies
 https://review.openstack.org/#/c/83150/

 it was figured that we need to find a way to use pip inner dependencies
 and
 we were able to do that, short info our solution and how it works:



- This is how regular requirements.txt looks:

 dep1

 …

 dep n


- This is how looks requirements.txt with inner dependencies:

 dep1

 -r somefolder/another-requirements.txt

 -r completelyanotherfolder/another-requirements.txt

 …

 dep n

 That’s what we’ve did for oslo.messaging. But we’ve faced with problem
 that
 was defined as openstack-infra/project-config

 tool issue, this tool called project-requirements-change
 https://github.com/openstack-infra/project-config/blob/master/jenkins/scripts/project-requirements-change.py
 .As you can see it’s not able to handle inner dependencies in any

 of requirements.txt files, as you can see this tool expects to parse only
 explicit set of requirements (see regular requirements.txt definition
 above).

 So, i decided to fix that tool to make it able to look over inner
 dependencies, and here’s https://review.openstack.org/#/c/153227/ what
 i
 have for yesterday,

 Taking into account suggestion from Monty Taylor i’m bringing this
 discussion to much wider audience.

 And the question is: aren’t we doing something complex or are there any
 less complex ways to

 accomplish the initial idea of splitting requirements?

 After re-reading this message, and discussing it with a few folks in the
 infra channel on IRC, I'm a little concerned that we don't have enough
 background to fully understand the problem and proposed solution. bnemec
 pointed out that the discussion happened before we had the spec process,
 but now that we do have that process I think the best next step is to
 have a spec written in oslo-specs describing the problem we're trying to
 solve and the approaches that were discussed. This may really just be
 summarizing the existing discussions, but let's get all of that
 information into a single document before we go any further.

 Doug



 Kind regards,

 Denis M.
 IRC: denis_makogon at Freenode
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Davanum Srinivas :: https://twitter.com/dims

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [infra][project-config][oslo.messaging] Pre-driver requirements split-up initiative

2015-02-06 Thread Denis Makogon
On Fri, Feb 6, 2015 at 4:00 PM, Jeremy Stanley fu...@yuggoth.org wrote:

 On 2015-02-06 14:37:08 +0200 (+0200), Denis Makogon wrote:
  As part of oslo.messaging initiative to split up requirements into
  certain list of per messaging driver dependencies
 [...]

 I'm curious what the end goal is here... when someone does `pip
 install oslo.messaging` what do you/they expect to get installed?
 Your run-parts style requirements.d plan is sort of
 counter-intuitive to me in that I would expect it to contain
 number-prefixed sublists of requirements which should be processed
 collectively in an alphanumeric sort order, but I get the impression
 this is not the goal of the mechanism (I'll be somewhat relieved if
 you tell me I'm mistaken in that regard).


Yes, that's the main goal, as i can foresee, to have an ability to install
oslo.messaging with dependencies for specific driver.


  Taking into account suggestion from Monty Taylor i’m bringing this
  discussion to much wider audience. And the question is: aren’t we
  doing something complex or are there any less complex ways to
  accomplish the initial idea of splitting requirements?

 As for taking this to a wider audience we (OpenStack) are already
 venturing into special snowflake territory with PBR, however
 requirements.txt is a convention used at least somewhat outside of
 OpenStack-related Python projects. It might make sense to get input
 from the broader Python packaging community on something like this
 before we end up alienating ourselves from them entirely.


Sure, that's what i'm looking for.


 --
 Jeremy Stanley

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Kind regards,
Denis M.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [infra][project-config][oslo.messaging] Pre-driver requirements split-up initiative

2015-02-06 Thread Denis Makogon
On Fri, Feb 6, 2015 at 4:16 PM, Donald Stufft don...@stufft.io wrote:


  On Feb 6, 2015, at 9:00 AM, Jeremy Stanley fu...@yuggoth.org wrote:
 
  On 2015-02-06 14:37:08 +0200 (+0200), Denis Makogon wrote:
  As part of oslo.messaging initiative to split up requirements into
  certain list of per messaging driver dependencies
  [...]
 
  I'm curious what the end goal is here... when someone does `pip
  install oslo.messaging` what do you/they expect to get installed?
  Your run-parts style requirements.d plan is sort of
  counter-intuitive to me in that I would expect it to contain
  number-prefixed sublists of requirements which should be processed
  collectively in an alphanumeric sort order, but I get the impression
  this is not the goal of the mechanism (I'll be somewhat relieved if
  you tell me I'm mistaken in that regard).
 
  Taking into account suggestion from Monty Taylor i’m bringing this
  discussion to much wider audience. And the question is: aren’t we
  doing something complex or are there any less complex ways to
  accomplish the initial idea of splitting requirements?
 
  As for taking this to a wider audience we (OpenStack) are already
  venturing into special snowflake territory with PBR, however
  requirements.txt is a convention used at least somewhat outside of
  OpenStack-related Python projects. It might make sense to get input
  from the broader Python packaging community on something like this
  before we end up alienating ourselves from them entirely.

 I’m not sure what exactly is trying to be achieved here, but I still assert
 that requirements.txt is the wrong place for pbr to be looking and it
 should
 instead look for dependencies specified inside of a setup.cfg.

 Sorry, i had to explain what i meant by saying 'inner dependency'. Let me
be more clear at this step to avoid misunderstanding in terminology.
Inner  dependency - is a redirection from requirements.txt to another file
that contains additional dependencies (-r another_deps.txt)

 More on topic, I'm not sure what inner dependencies are, but if what
 you're
 looking for is optional dependencies that only are needed in specific
 situation
 then you probably want extras, defined like:

 setup(
 extras_require={
 somename: [
 dep1,
 dep2,
 ],
 },
 )


That might be the case, but since we want to split up requirements into
per-driver dependecies, it would require to check if setup.cfg can handle
use of inner dependencies. for example:

setup(
extras_require={
somename: [
-r another_file_with_deps.txt,
],
},
)


 Then if you do ``pip install myproject[somename]`` it'll include dep1 and
 dep2
 in the list of dependencies, you can also depend on this in other projects
 like:

 setup(
 install_requires=[myproject[somename]=1.0],
 )


That's i've been looking for, so, for future installations it'll be very
useful if cloud deployer knows which AMQP service will be used,
then he'd be able to install only that type of oslo.messaging that he wants
i.e.

project/requirements.txt:
...
oslo.messaging[amqp1]=${version}

...

Really great input, thanks Donald. Appreciate it.

---
 Donald Stufft
 PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Kind regards,
Denis M.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [infra][project-config][oslo.messaging] Pre-driver requirements split-up initiative

2015-02-06 Thread Denis Makogon
On Fri, Feb 6, 2015 at 5:54 PM, Doug Hellmann d...@doughellmann.com wrote:



 On Fri, Feb 6, 2015, at 09:56 AM, Denis Makogon wrote:
  On Fri, Feb 6, 2015 at 4:16 PM, Donald Stufft don...@stufft.io wrote:
 
  
On Feb 6, 2015, at 9:00 AM, Jeremy Stanley fu...@yuggoth.org
 wrote:
   
On 2015-02-06 14:37:08 +0200 (+0200), Denis Makogon wrote:
As part of oslo.messaging initiative to split up requirements into
certain list of per messaging driver dependencies
[...]
   
I'm curious what the end goal is here... when someone does `pip
install oslo.messaging` what do you/they expect to get installed?
Your run-parts style requirements.d plan is sort of
counter-intuitive to me in that I would expect it to contain
number-prefixed sublists of requirements which should be processed
collectively in an alphanumeric sort order, but I get the impression
this is not the goal of the mechanism (I'll be somewhat relieved if
you tell me I'm mistaken in that regard).
   
Taking into account suggestion from Monty Taylor i’m bringing this
discussion to much wider audience. And the question is: aren’t we
doing something complex or are there any less complex ways to
accomplish the initial idea of splitting requirements?
   
As for taking this to a wider audience we (OpenStack) are already
venturing into special snowflake territory with PBR, however
requirements.txt is a convention used at least somewhat outside of
OpenStack-related Python projects. It might make sense to get input
from the broader Python packaging community on something like this
before we end up alienating ourselves from them entirely.
  
   I’m not sure what exactly is trying to be achieved here, but I still
 assert
   that requirements.txt is the wrong place for pbr to be looking and it
   should
   instead look for dependencies specified inside of a setup.cfg.
  
   Sorry, i had to explain what i meant by saying 'inner dependency'. Let
 me
  be more clear at this step to avoid misunderstanding in terminology.
  Inner  dependency - is a redirection from requirements.txt to another
  file
  that contains additional dependencies (-r another_deps.txt)
 
   More on topic, I'm not sure what inner dependencies are, but if what
   you're
   looking for is optional dependencies that only are needed in specific
   situation
   then you probably want extras, defined like:
  
   setup(
   extras_require={
   somename: [
   dep1,
   dep2,
   ],
   },
   )
  
  
  That might be the case, but since we want to split up requirements into
  per-driver dependecies, it would require to check if setup.cfg can handle
  use of inner dependencies. for example:
 
  setup(
  extras_require={
  somename: [
  -r another_file_with_deps.txt,
  ],
  },
  )

 Let's see if we can make pbr add the extras_require values. We can then
 either specify the requirements explicitly in setup.cfg, or use a naming
 convention for separate requirements files. Either way, we shouldn't
 need setuptools to understand that we are managing the list of
 requirements in files.


That might be the case. And probably PBR is the only place where we can
place that logic since distutils already can do that.

Doug, i will take a look at PBR and will try to figure out the easiest way
to get extras_require into it. Thanks for input.


 
   Then if you do ``pip install myproject[somename]`` it'll include dep1
 and
   dep2
   in the list of dependencies, you can also depend on this in other
 projects
   like:
  
   setup(
   install_requires=[myproject[somename]=1.0],
   )
  
  
  That's i've been looking for, so, for future installations it'll be very
  useful if cloud deployer knows which AMQP service will be used,
  then he'd be able to install only that type of oslo.messaging that he
  wants
  i.e.
 
  project/requirements.txt:
  ...
  oslo.messaging[amqp1]=${version}
 
  ...
 
  Really great input, thanks Donald. Appreciate it.
 
  ---
   Donald Stufft
   PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
  
  
  
 __
   OpenStack Development Mailing List (not for usage questions)
   Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
 
  Kind regards,
  Denis M.
 
 __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: 

Re: [openstack-dev] [infra][project-config][oslo.messaging] Pre-driver requirements split-up initiative

2015-02-06 Thread Ben Nemec
On 02/06/2015 10:12 AM, Doug Hellmann wrote:
 
 
 On Fri, Feb 6, 2015, at 07:37 AM, Denis Makogon wrote:
 Hello to All.


 As part of oslo.messaging initiative to split up requirements into
 certain
 list of per messaging driver dependencies
 https://review.openstack.org/#/c/83150/

 it was figured that we need to find a way to use pip inner dependencies
 and
 we were able to do that, short info our solution and how it works:



- This is how regular requirements.txt looks:

 dep1

 …

 dep n


- This is how looks requirements.txt with inner dependencies:

 dep1

 -r somefolder/another-requirements.txt

 -r completelyanotherfolder/another-requirements.txt

 …

 dep n

 That’s what we’ve did for oslo.messaging. But we’ve faced with problem
 that
 was defined as openstack-infra/project-config

 tool issue, this tool called project-requirements-change
 https://github.com/openstack-infra/project-config/blob/master/jenkins/scripts/project-requirements-change.py
 .As you can see it’s not able to handle inner dependencies in any

 of requirements.txt files, as you can see this tool expects to parse only
 explicit set of requirements (see regular requirements.txt definition
 above).

 So, i decided to fix that tool to make it able to look over inner
 dependencies, and here’s https://review.openstack.org/#/c/153227/ what
 i
 have for yesterday,

 Taking into account suggestion from Monty Taylor i’m bringing this
 discussion to much wider audience.

 And the question is: aren’t we doing something complex or are there any
 less complex ways to

 accomplish the initial idea of splitting requirements?
 
 After re-reading this message, and discussing it with a few folks in the
 infra channel on IRC, I'm a little concerned that we don't have enough
 background to fully understand the problem and proposed solution. bnemec
 pointed out that the discussion happened before we had the spec process,
 but now that we do have that process I think the best next step is to
 have a spec written in oslo-specs describing the problem we're trying to
 solve and the approaches that were discussed. This may really just be
 summarizing the existing discussions, but let's get all of that
 information into a single document before we go any further.

For reference, here are the major discussions I'm aware of around this
issue:

http://lists.openstack.org/pipermail/openstack-dev/2014-February/026976.html

http://lists.openstack.org/pipermail/openstack-dev/2015-January/055229.html

https://bugs.launchpad.net/heat/+bug/1225191

https://bugs.launchpad.net/neutron/+bug/1225232

-Ben



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev