[openstack-dev] [Neutron] Using Python-Neutronclient from
WICKES, ROGER
rw314w at att.com
Mon Feb 10 15:12:04 UTC 2014
All dictionaries are not created equal; in some respects it's like we have a medical dictionary and an automotive terms dictionary and on for each api. So, we need to document our dictionaries, by which key names (and possibly sample values) are required in the dictionary and which are optional (and when), for that particular API (e.g. create_credential) to work as expected.
------------------------------
Message: 3
Date: Sat, 8 Feb 2014 19:20:02 +0000
From: "Collins, Sean" <Sean_Collins2 at cable.comcast.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [Neutron] Using Python-Neutronclient from
Python - docstrings needed?
Message-ID: <20140208192001.GB40776 at HQSML-1081034.cable.comcast.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I was writing a small script yesterday to parse a list of IP blocks and
create security groups and rules, by using python-neutronclient.
To be honest, it was very difficult - even though I have actually
written extensions to Python-Neutronclient for the QoS API.
For those that are trying to use the client from inside their code,
they end up getting zero help as to how to actually call any of the
functions, and what parameters they take.
>>> neutron = client.Client('2.0', auth_url=os.environ['OS_AUTH_URL'],
... tenant_id=os.environ['OS_TENANT_ID'],
... username=os.environ['OS_USERNAME'],
... password=os.environ['OS_PASSWORD'])
>>> help(neutron)
| create_credential = <function with_params>
|
| create_firewall = <function with_params>
|
| create_firewall_policy = <function with_params>
|
| create_firewall_rule = <function with_params>
|
| create_floatingip = <function with_params>
|
| create_health_monitor = <function with_params>
|
| create_ikepolicy = <function with_params>
|
| create_ipsec_site_connection = <function with_params>
|
| create_ipsecpolicy = <function with_params>
|
| create_member = <function with_params>
|
| create_metering_label = <function with_params>
Since there was nothing there, I decided to go check the source of
python-neutronclient and see if there are any examples.
https://github.com/openstack/python-neutronclient/blob/master/doc/source/index.rst
If you read closely enough, you'll find out that the function takes a
dictionary, that looks very similar to the request/response examples
listed in the API documentation. So, I went over and checked it out.
http://docs.openstack.org/api/openstack-network/2.0/content/POST_security-groups-v2.0_createSecGroup_v2.0_security-groups_security-groups-ext.html
So from there, I was able to remember enough that each of these
functions takes a single argument, that is a dictionary, that mimics
the same structure that you see in the API documentation, so from there
it was just some experimentation to get the structure right.
Honestly it wasn't easy to remember all this stuff, since
it had been a couple months since I had worked with
python-neutronclient, and it had been from inside the library itself.
This was my first experience using it "on the outside" and it was pretty
tough - so I'm going to try and look into how we can improve the
docstrings for the client object, to make it a bit easier to figure out.
Thoughts?
--
Sean M. Collins
------------------------------
Message: 4
Date: Sat, 8 Feb 2014 14:22:24 -0800
From: Georgy Okrokvertskhov <gokrokvertskhov at mirantis.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [heat] non-trivial example - IBM
Connections [and Murano]
Message-ID:
<CAG_6_o=22iR7HJKBSRpkJ6f3-3bLrHcaSC-mLU=6S3JnoeL96A at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Mike,
Thank you for clarification. I like your approach with Ruby and I think
this is a right way to solve such tasks like DSL creation. In Murano we use
Yaml and python just to avoid introduction of a whole new language like
Ruby to OpenStack.
As for software configurations in heat, we are eager to have it available
for use. We use Heat in Murano and we want to pass as much as possible work
to Heat engine. Murano itself is intended to be an Application Catalog for
managing available application packages and focuses on UI and user
experience rather then on deployment details. We still use DSL for several
things, have something working while waiting for Heat implementations, and
to have imperative workflow engine which is useful when you need to
orchestrate complex workflows. The last part is very powerful when you need
to have an explicit control on deployment sequence with conditional
branches orchestration among several different instances. When Mistral will
be available we plan to use its workflow engine for task orchestration.
Again, thank you for sharing the work you are doing in IBM. This is very
good feedback for OpenStack community and helps to understand how OpenStack
components used in enterprise use cases.
Thanks
Georgy
On Sat, Feb 8, 2014 at 10:52 AM, Mike Spreitzer <mspreitz at us.ibm.com> wrote:
> > From: Georgy Okrokvertskhov <gokrokvertskhov at mirantis.com>
> > ...
> > Thank you for sharing this. It looks pretty impressive. Could you,
> > please some details about DSL syntax, if it is possible?
>
> I will respond briefly, and pass your request along to the people working
> on that.
>
> In the Weaver language there are distinct concepts for software
> configuration vs. things (such as VMs) that can host software configs. As
> in the current software config work, there are distinct concepts for
> defining a software configuration vs. applying one to some particular
> infrastructure. Weaver supposes that local configuration is described in
> Chef; Weaver adds a way of connecting chef variables across machines. So
> you see, there are a lot of similarities with the current work on software
> config, which I support.
>
> Weaver takes advantage of the power of Ruby metaprogramming to add pretty
> natural and concise constructs for modeling infrastructure and software
> config. The source does not look like it is one level off, it looks like
> it is describing a thing rather than describing how to build a model of the
> thing (even though that is what it is actually doing).
>
> Embedding in Ruby adds powerful and familiar support for abstraction and
> customized repetition in descriptions of distributed systems. This is
> going to be hard to do nicely in a language (regardless of whether it uses
> JSON or YAML syntax) that is primarily for data representation. One of the
> points of sharing this example was to show a system for which you would
> like such power.
>
> What is the unique problem that Murano is addressing? The current
> software config work can deploy multiple configs to a target. Supposing
> that the local config (the non-distributed base configuration management
> tool involved, which is open in the current software config work) is
> expressed using something sufficiently powerful (chef and bash are
> examples), the local config language can do abstraction and composition in
> the description of local configuration.
>
> Regards,
> Mike
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140208/778d1d1d/attachment-0001.html>
------------------------------
Message: 5
Date: Sun, 09 Feb 2014 00:08:01 +0000
From: Monty Taylor <mordred at inaugust.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: [openstack-dev] universal wheel support
Message-ID: <52F6C6E1.6070303 at inaugust.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hey all!
There are a bunch of patches adding:
[wheel]
universal = 1
to setup.cfg:
https://review.openstack.org/#/q/status:open+topic:wheel-publish,n,z
I wanted to follow up on what the deal is with them, and what I think we
should do about them.
universal means that a wheel can be made that can work with any python.
That's awesome, and we want it - it makes the wheel publishing code
easier. I don't think we want it turned on for any project that doesn't,
in fact, support python3 - because we'd be producing a wheel that says
it works in python3.
To be fair - the wheel itself will work just fine in python3 - it's just
the software that doesn't - and we upload tarballs right now which don't
block attempts to use them in python3.
SO -
my pedantic side says:
"Let's only land universal = 1 into python3 supporting projects"
upon further reflection, I think my other side says:
"It's fine, let's land it everywhere, it doesn't hurt anything, and then
we can stop worrying about it"
Thoughts?
Monty
------------------------------
Message: 6
Date: Sat, 8 Feb 2014 19:18:09 -0500
From: Donald Stufft <donald at stufft.io>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] universal wheel support
Message-ID: <1C9D208A-EFF8-4BF8-A8E2-275AAA8D984F at stufft.io>
Content-Type: text/plain; charset="windows-1252"
On Feb 8, 2014, at 7:08 PM, Monty Taylor <mordred at inaugust.com> wrote:
> Hey all!
>
> There are a bunch of patches adding:
>
> [wheel]
> universal = 1
>
> to setup.cfg:
>
> https://review.openstack.org/#/q/status:open+topic:wheel-publish,n,z
>
> I wanted to follow up on what the deal is with them, and what I think we should do about them.
>
> universal means that a wheel can be made that can work with any python. That's awesome, and we want it - it makes the wheel publishing code easier. I don't think we want it turned on for any project that doesn't, in fact, support python3 - because we'd be producing a wheel that says it works in python3.
>
> To be fair - the wheel itself will work just fine in python3 - it's just the software that doesn't - and we upload tarballs right now which don't block attempts to use them in python3.
>
> SO -
>
> my pedantic side says:
>
> "Let's only land universal = 1 into python3 supporting projects"
>
> upon further reflection, I think my other side says:
>
> "It's fine, let's land it everywhere, it doesn't hurt anything, and then we can stop worrying about it"
>
> Thoughts?
>
> Monty
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Techincally you can upload a Wheel that supports any Python version, but I don?t believe it?s exposed in the Wheel software at all.
However the side effect of publishing a py2 only wheel is that if someone tries to install that package using python3, instead of a Wheel they?ll download the sdist and try to install that. There?s a good chance that will install fine, just as a Wheel would, and the error won?t be discovered until they try to run it.
Essentially the wheel tags are supposed to be used to determine which Wheel is most likely to be compatible with the environment that is being installed into, it is not designed to restrict which environments a project supports. There is metadata for that in the new PEPs but nothing supports it yet.
-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140208/29965e96/attachment-0001.pgp>
------------------------------
Message: 7
Date: Sat, 8 Feb 2014 19:22:57 -0500
From: Donald Stufft <donald at stufft.io>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] universal wheel support
Message-ID: <F1ED1E02-2997-4739-B0B5-F265C9C3A877 at stufft.io>
Content-Type: text/plain; charset="windows-1252"
On Feb 8, 2014, at 7:18 PM, Donald Stufft <donald at stufft.io> wrote:
> Techincally you can upload a Wheel that supports any Python version, but I don?t believe it?s exposed in the Wheel software at all.
This is supposed to be ?any Python2 version?.
-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140208/8c556430/attachment-0001.pgp>
------------------------------
Message: 8
Date: Sun, 9 Feb 2014 01:18:24 +0000
From: "Collins, Sean" <Sean_Collins2 at cable.comcast.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Nova] Gate broken
Message-ID: <20140209011815.GA62880 at HQSML-1081034>
Content-Type: text/plain; charset="utf-8"
Ah, so they fixed the issue the blog post by AppNeta[0] brought up. Very
Cool!
http://www.appneta.com/blog/s3-list-get-bucket-default/
https://github.com/boto/boto/issues/2078
--
Sean M. Collins
------------------------------
Message: 9
Date: Sat, 08 Feb 2014 20:53:03 -0600
From: Matt Riedemann <mriedem at linux.vnet.ibm.com>
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [nova][ceilometer] Removing
simple_tenant_usage and os-instance_usage_audit_log from V3 API
Message-ID: <52F6ED8F.5060804 at linux.vnet.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 2/7/2014 4:10 PM, Joe Gordon wrote:
> Hi All,
>
> I would like to propose removing the simple_tenant_usage and
> os-instance_usage_audit_log extensions from the nova V3 API (while
> keeping them in V2). Both of these are pre ceilometer extensions to
> generate rudimentary usage information, something that we should be
> using ceilometer for.
>
> For those of you who aren't sure what os-instance_usage_audit_log is:
> * https://github.com/openstack/nova/commit/2fdd73816c56b578a65466db4e5a86b9b191e1c1
> * No python-novaclient support
> * output from a devstack run http://paste.ubuntu.com/6893886/
+1
Not to mention no api-ref docs for os-instance_usage_audit_log.
>
>
>
> best,
> Joe
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Thanks,
Matt Riedemann
------------------------------
Message: 10
Date: Sat, 8 Feb 2014 20:10:13 -0800 (PST)
From: Rajdeep Dua <dua_rajdeep at yahoo.com>
To: "OpenStack Development Mailing List \(not for usage questions\)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron] Using Python-Neutronclient from
Python - docstrings needed?
Message-ID:
<1391919013.65978.YahooMailNeo at web163804.mail.gq1.yahoo.com>
Content-Type: text/plain; charset="iso-8859-1"
Sean,
We have written a few docs for writing these samples
http://python-api-guide.cfapps.io/content/neutron.html
You can find get the source here?https://github.com/rajdeepd/openstack-samples
Thanks
Rajdeep
On Sunday, February 9, 2014 12:57 AM, "Collins, Sean" <Sean_Collins2 at cable.comcast.com> wrote:
Hi,
I was writing a small script yesterday to parse a list of IP blocks and
create security groups and rules, by using python-neutronclient.
To be honest, it was very difficult - even though I have actually
written extensions to Python-Neutronclient for the QoS API.
For those that are trying to use the client from inside their code,
they end up getting zero help as to how to actually call any of the
functions, and what parameters they take.
? ? >>> neutron = client.Client('2.0', auth_url=os.environ['OS_AUTH_URL'],
? ? ...? ? ? ? ? ? ? ? ? ? ? ? ? ? tenant_id=os.environ['OS_TENANT_ID'],
? ? ...? ? ? ? ? ? ? ? ? ? ? ? ? ? username=os.environ['OS_USERNAME'],
? ? ...? ? ? ? ? ? ? ? ? ? ? ? ? ? password=os.environ['OS_PASSWORD'])
? ? >>> help(neutron)
? |? create_credential = <function with_params>
? |?
? |? create_firewall = <function with_params>
? |?
? |? create_firewall_policy = <function with_params>
? |?
? |? create_firewall_rule = <function with_params>
? |?
? |? create_floatingip = <function with_params>
? |?
? |? create_health_monitor = <function with_params>
? |?
? |? create_ikepolicy = <function with_params>
? |?
? |? create_ipsec_site_connection = <function with_params>
? |?
? |? create_ipsecpolicy = <function with_params>
? |?
? |? create_member = <function with_params>
? |?
? |? create_metering_label = <function with_params>
Since there was nothing there, I decided to go check the source of
python-neutronclient and see if there are any examples.
https://github.com/openstack/python-neutronclient/blob/master/doc/source/index.rst
If you read closely enough, you'll find out that the function takes a
dictionary, that looks very similar to the request/response examples
listed in the API documentation. So, I went over and checked it out.
http://docs.openstack.org/api/openstack-network/2.0/content/POST_security-groups-v2.0_createSecGroup_v2.0_security-groups_security-groups-ext.html
So from there, I was able to remember enough that each of these
functions takes a single argument, that is a dictionary, that mimics
the same structure that you see in the API documentation, so from there
it was just some experimentation to get the structure right.
Honestly it wasn't easy to remember all this stuff, since
it had been a couple months since I had worked with
python-neutronclient, and it had been from inside the library itself.
This was my first experience using it "on the outside" and it was pretty
tough - so I'm going to try and look into how we can improve the
docstrings for the client object, to make it a bit easier to figure out.
Thoughts?
--
Sean M. Collins
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140208/fe2e9989/attachment-0001.html>
------------------------------
Message: 11
Date: Sun, 9 Feb 2014 07:49:59 +0000
From: "ELISHA, Moshe (Moshe)" <moshe.elisha at alcatel-lucent.com>
To: "openstack-dev at lists.openstack.org"
<openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [heat] Can heat automatically create a flavor
as part of stack creation?
Message-ID:
<68E0028885A28B42BA72B18D58B31E8E26DB30 at FR711WXCHMBA07.zeu.alcatel-lucent.com>
Content-Type: text/plain; charset="us-ascii"
Hello,
I am wondering if instead of being obligated to use an existing flavor, I could declare a flavor (with its properties) inside Heat template and let Heat create the flavor automatically?
Similar to the ability to create networks as part of the template.
Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140209/d763c587/attachment-0001.html>
------------------------------
Message: 12
Date: Sun, 9 Feb 2014 21:09:50 +1300
From: Robert Collins <robertc at robertcollins.net>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [heat] Can heat automatically create a
flavor as part of stack creation?
Message-ID:
<CAJ3HoZ0wuh_tvqTDNxAfRgcZc9k6Ba8Kmhx0QUb=gcVmL=R-Ww at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
In principle yes.
You need:
- to write a module to orchestrate the nova flavor API.
- to configure your policy rules in the cloud in question to let the
heat engine user create flavors
-Rob
On 9 February 2014 20:49, ELISHA, Moshe (Moshe)
<moshe.elisha at alcatel-lucent.com> wrote:
> Hello,
>
>
>
> I am wondering if instead of being obligated to use an existing flavor, I
> could declare a flavor (with its properties) inside Heat template and let
> Heat create the flavor automatically?
>
> Similar to the ability to create networks as part of the template.
>
>
>
> Thanks.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud
------------------------------
Message: 13
Date: Sun, 9 Feb 2014 00:19:57 -0800
From: Gary Kotton <gkotton at vmware.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Nova] Gate broken
Message-ID: <CF1D06C5.44463%gkotton at vmware.com>
Content-Type: text/plain; charset="us-ascii"
Thanks for fixing this.
From: Qiu Yu <unicell at gmail.com<mailto:unicell at gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Saturday, February 8, 2014 9:44 AM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [Nova] Gate broken
On Sat, Feb 8, 2014 at 3:29 PM, Gary Kotton <gkotton at vmware.com<mailto:gkotton at vmware.com>> wrote:
Hi,
Anyone aware of:
It is caused the new boto 2.25 release.
Joe Gordon filed a new bug on this[1], and I just submitted a patch [2] to fix.
[1] https://bugs.launchpad.net/nova/+bug/1277790<https://urldefense.proofpoint.com/v1/url?u=https://bugs.launchpad.net/nova/%2Bbug/1277790&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=vI%2BXgZM0Jp3%2FXnNc6HdXuLiyoSz9X9STn67VyRUuQFE%3D%0A&s=fd96e0f368b4d139e35c6b7a37c7234dbcb580e81a49fd4fc2b5c5bc95535e0d>
[2] https://review.openstack.org/#/c/72066/<https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/%23/c/72066/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=vI%2BXgZM0Jp3%2FXnNc6HdXuLiyoSz9X9STn67VyRUuQFE%3D%0A&s=4eaee74f7d34704dd0e64d6ecbb345ea8f51e1e02cf2532d191d3145d84c1416>
Thanks,
--
Qiu Yu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140209/39c568a5/attachment-0001.html>
------------------------------
Message: 14
Date: Sun, 9 Feb 2014 10:33:09 +0200
From: Alex Glikson <GLIKSON at il.ibm.com>
To: "OpenStack Development Mailing List \(not for usage questions\)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [heat] Can heat automatically create a
flavor as part of stack creation?
Message-ID:
<OFA6CAECEE.26B71567-ONC2257C7A.002EADAE-C2257C7A.002EFFB9 at il.ibm.com>
Content-Type: text/plain; charset="us-ascii"
Heat template orchestrates user actions, while management of flavors is
typically admin's job (due to their tight link to the physical hardware
configuration, unknown to a regular user).
Regards,
Alex
From: "ELISHA, Moshe (Moshe)" <moshe.elisha at alcatel-lucent.com>
To: "openstack-dev at lists.openstack.org"
<openstack-dev at lists.openstack.org>,
Date: 09/02/2014 09:54 AM
Subject: [openstack-dev] [heat] Can heat automatically create a
flavor as part of stack creation?
Hello,
I am wondering if instead of being obligated to use an existing flavor, I
could declare a flavor (with its properties) inside Heat template and let
Heat create the flavor automatically?
Similar to the ability to create networks as part of the template.
Thanks._______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140209/c31e2b47/attachment-0001.html>
------------------------------
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
End of OpenStack-dev Digest, Vol 22, Issue 23
*********************************************
More information about the OpenStack-dev
mailing list