[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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Using Python-Neutronclient from Python - docstrings needed?
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"
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 =
|
| create_firewall =
|
| create_firewall_policy =
|
| create_firewall_rule =
|
| create_floatingip =
|
| create_health_monitor =
|
| create_ikepolicy =
|
| create_ipsec_site_connection =
|
| create_ipsecpolicy =
|
| create_member =
|
| create_metering_label =
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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][ceilometer] Removing simple_tenant_usage and os-instance_usage_audit_log from V3 API
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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Thanks, Matt Riedemann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Gate broken
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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] universal wheel support
On Feb 8, 2014, at 7:18 PM, Donald Stufft 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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] universal wheel support
On Feb 8, 2014, at 7:08 PM, Monty Taylor 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@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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] universal wheel support
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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] non-trivial example - IBM Connections [and Murano]
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 wrote: > > From: Georgy Okrokvertskhov > > ... > > 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@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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Using Python-Neutronclient from Python - docstrings needed?
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 =
|
| create_firewall =
|
| create_firewall_policy =
|
| create_firewall_rule =
|
| create_floatingip =
|
| create_health_monitor =
|
| create_ikepolicy =
|
| create_ipsec_site_connection =
|
| create_ipsecpolicy =
|
| create_member =
|
| create_metering_label =
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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] non-trivial example - IBM Connections [and Murano]
> From: Georgy Okrokvertskhov > ... > 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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] pep8 barfs on long URL
On 02/07/2014 08:57 PM, Joe Gordon wrote: > On Fri, Feb 7, 2014 at 6:40 AM, Jay Pipes wrote: >> On Fri, 2014-02-07 at 15:36 +0100, Julien Danjou wrote: >>> On Fri, Feb 07 2014, Jay Pipes wrote: >>> On Fri, 2014-02-07 at 14:25 +, Matthew Booth wrote: > I have a comment which references a long URL. The URL itself is longer > than 80 characters. Jenkins has flagged this as a pep8 failure, because > the line is longer than 80 characters. > > This is an instance where in the past I have always applied common sense > to the line length limit. You either have a long line or a broken URL. > As the long line is more usable in this instance, it's the lesser of 2 > evils. > > Is there a mechanism to to coerce Jenkins to allow it? Failing that, is > there a mechanism to manually ignore a specific Jenkins failure? Failing > that, is there a project convention for broken URLs? How about using a service like bit.ly to shorten the URL? Would that be acceptable? >>> >>> This would be ridiculous. :-/ >> >> ? Why would that be ridiculous? I'm not talking about having pep8 use >> bit.ly. I'm talking about Matthew just shortening the URL with bit.ly >> and putting the shortened URL in the comment. >> >>> Isn't #noqa working on such error? >> >> Yes, as I mentioned in a follow up... > > E501 (line too long) can be disabled at the line level using the # > noqa special comment > > Source: http://pep8.readthedocs.org/en/latest/intro.html#error-codes Sure, but honestly, putting a random url from the internet in source code seems largely not useful. Because how long do we expect that url to be valid? A month, a year? The summary rationale for that should be pulled in, feel free to put something in a review comment or the commit on upstream reference, but having urls for external url in source code is just debt. -Sean -- Sean Dague Samsung Research America s...@dague.net / sean.da...@samsung.com http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Developer documentation - linking to slideshares?
My slides are also available to be used. On Thu, Feb 6, 2014 at 2:27 AM, Collins, Sean < sean_colli...@cable.comcast.com> wrote: > On Tue, Feb 04, 2014 at 07:52:22AM -0600, Anne Gentle wrote: > > Currently the docs contributor sign the same CLA as code contributors. > I'd > > encourage you to use the docs to really explain not just link to slide > > decks. There's a better chance of maintenance over time. > > Agreed - I plan on writing up docs, but when I find something really > good on a slide I'd like to be able to have a reference to it in the > footnotes - I suppose a works cited section, so I'm not plagiarizing. > > > I had been using a wiki page for a collection of videos at > > https://wiki.openstack.org/wiki/Demo_Videos. But it ages with time. > > Awesome - I'll make sure to add that link to some kind of > "further reading" section. > > -- > Sean M. Collins > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic][Ceilometer]bp:send-data-to-ceilometer
Hi Wanyen, Thanks for your input first, I have worked out solution 1 enhanced version, that is very flexible framework from our Ironic part, will not change any data returned by 'ipmitool' command and just format them as JSON string and sent to ceilometer, this should be the final solution, will implement it with python code in our Ironic. The solution 1 enhanced version is: We run the ipmitool command with 'sdr -v' options, so we get details for each sensor, see the command line and out put as below link: http://paste.openstack.org/show/63267/ Our Ironic will parse these output to JSON string by 'Sensor Type', check the JSON string which will be sent to Ceilometer: http://paste.openstack.org/show/63276/ So from our Ironic part, we will support all sensors which returned from 'ipmitool sdr -v' command, that is flexible framework I think. For this my testing case result, we get a lot of below sensor types, including 'Fan', 'Voltage', 'Temperature' these three common sensors: ['Cable / Interconnect', 'Physical Security', 'System Firmwares', 'Temperature', 'Drive Slot / Bay', 'Battery', 'Unknown (0xC1)', 'Memory', 'Power Supply', 'System Event', 'Module / Board', 'Version Change', 'Fan', 'Voltage', 'Event Logging Disabled', 'Critical Interrupt', 'Watchdog', 'Processor', 'Entity Presence'] However, from Ceilometer part, have to define the 'Meter' data model with these JSON input from our Ironic, so for first version, I think our Ceilometer will support 'Fan', 'Voltage', 'Temperature' first, and will check with Ceilometer team guys how to model/map these ipmi sensor data as ceilometer resource->meter->samples and support more flexibility to accomodate more sensors like our Ironic:) Thanks Haomeng On Sat, Feb 8, 2014 at 6:20 AM, Hsu, Wan-Yen wrote: >>Haomeng wrote: > > > >>Ok, will implement the bp based on the first solution, thanks. > > > > > > I believe solution 2 is more flexible and it allows hardware to report > additional sensors than solution 1. However, if there is a desire to define > specific sensor categories as proposed by solution 1, then please add an > extra-sensors data structure with key+ value pairs to allow different > hardware to report additional sensors such as average wattage, critical > upper temperature threshold, network, and memory sensors, ...etc. Thanks! > > > > > > Regards, > > Wanyen > > > > > > > > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic][Ceilometer]bp:send-data-to-ceilometer
Hi Wanyen, Thanks for your input first, I have worked out solution 1 enhanced version, that is very flexible framework from our Ironic part, will not change any data returned by 'ipmitool' command and just format them as JSON string and sent to ceilometer, I think this should be the final solution, I will implement it with python code in our Ironic. The solution 1 enhanced version is: We run the ipmitool command with 'sdr -v' options, so we get details for each sensor, see the command line and out put as below link: http://paste.openstack.org/show/63267/ Our Ironic will parse these output to JSON string by 'Sensor Type', check the JSON string which will be sent to Ceilometer: http://paste.openstack.org/show/63276/ So from our Ironic part, we will support all sensors which returned from 'ipmitool sdr -v' command, that is flexible framework I think. For this my testing case result, we get a lot of below sensor types, including 'Fan', 'Voltage', 'Temperature' these three common sensors: ['Cable / Interconnect', 'Physical Security', 'System Firmwares', 'Temperature', 'Drive Slot / Bay', 'Battery', 'Unknown (0xC1)', 'Memory', 'Power Supply', 'System Event', 'Module / Board', 'Version Change', 'Fan', 'Voltage', 'Event Logging Disabled', 'Critical Interrupt', 'Watchdog', 'Processor', 'Entity Presence'] However, from Ceilometer part, have to define the 'Meter' data model with these JSON input from our Ironic, so for first version, I think our Ceilometer will support 'Fan', 'Voltage', 'Temperature' first, and will check with Ceilometer team guys how to model/map these ipmi sensor data as ceilometer resource->meter->samples and support more flexibility to accomodate more sensors like our Ironic:) Thanks Haomeng On Sat, Feb 8, 2014 at 6:20 AM, Hsu, Wan-Yen wrote: >>Haomeng wrote: > > > >>Ok, will implement the bp based on the first solution, thanks. > > > > > > I believe solution 2 is more flexible and it allows hardware to report > additional sensors than solution 1. However, if there is a desire to define > specific sensor categories as proposed by solution 1, then please add an > extra-sensors data structure with key+ value pairs to allow different > hardware to report additional sensors such as average wattage, critical > upper temperature threshold, network, and memory sensors, ...etc. Thanks! > > > > > > Regards, > > Wanyen > > > > > > > > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
