Re: [openstack-dev] [heat] update_allowed vs. immutable
Hi Praveen, The docs you referred to in the plugin guide is for the resource property attributes - they have nothing to do with parameters. This is an important distinction because there is also an "immutable" parameter attribute. The "immutable" property attribute was added because an equivalent to AWS' "Updates are not supported" functionality was needed: https://specs.openstack.org/openstack/heat-specs/specs/juno/implement-aws-updates-not-supported.html#aws-cloudformation Jason From: Praveen Yalagandula Sent: Monday, May 2, 2016 11:55 AM To: OpenStack Development Mailing List Subject: [openstack-dev] [heat] update_allowed vs. immutable What is the difference between "update_allowed" and "immutable" parameters for a property? According to the plugin guide at http://docs.openstack.org/developer/heat/developing_guides/pluginguide.html: update_allowed: True if an existing resource can be updated, False means update is accomplished by delete and re-create. Default is False. immutable: True means updates are not supported, resource update will fail on every change of this property. False otherwise. Default is False. Since any resource can be deleted and then re-created, it seems "update_allowed" is the right parameter to define. Why do we need "immutable"? Thanks, Praveen Yalagandula Avi Networks __ 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] [heat] Unable to launch nova instance with the new flavor
Hi Bharath,
It sounds like you've hit this bug https://bugs.launchpad.net/heat/+bug/1556317
A fix is in progress https://review.openstack.org/#/c/291971/?
Regards,
Jason
From: bharath thiruveedula
Sent: Monday, March 14, 2016 1:12 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [heat] Unable to launch nova instance with the new
flavor
Hi,
With the master branch, I couldn't launch heat stack with the following
template, giving the error "ERROR: No Flavor matching {'name': u'flavor_1'}.
(HTTP 404)"
heat_template_version: 2015-04-30
description: Simple template to deploy a single compute instance
resources:
ins1:
type: OS::Nova::Server
properties:
flavor: {get_resource: flavor_1}
image: Fedora
flavor_1:
type: OS::Nova::Flavor
properties:
disk: 1
vcpus: 1
ram: 1
But with "stable/liberty" branch, I can launch the heat stack.
Anyone aware of this issue? Can anyone help me on this issue?
Regards
Bharath T
__
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] [Heat] core team nomination
+1! From: Sergey Kraynev Sent: Tuesday, October 20, 2015 8:38 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Heat] core team nomination I'd like to propose new candidates for heat core-team: Rabi Mishra Peter Razumovsky According statistic both candidate made a big effort in Heat as reviewers and as contributors [1][2]. They were involved in Heat community work during last several releases and showed good understanding of Heat code. I think, that they are ready to became core-reviewers. Heat-cores, please vote with +/- 1. [1] http://stackalytics.com/report/contribution/heat-group/180 [2] http://stackalytics.com/?module=heat-group&metric=person-day -- Regards, Sergey. __ 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] [Heat] core team changes
+1 On Tue, Jan 27 2015, Angus Salkeld wrote: > Hi all > > After having a look at the stats: > http://stackalytics.com/report/contribution/heat-group/90 > http://stackalytics.com/?module=heat-group&metric=person-day > > I'd like to propose the following changes to the Heat core team: > > Add: > Qiming Teng > Huang Tianhua > > Remove: > Bartosz Górski (Bartosz has indicated that he is happy to be removed and > doesn't have the time to work on heat ATM). > > Core team please respond with +/- 1. > > Thanks > Angus > __ > 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] [Heat] Nominating Pavlo Shchelokovskyy for heat-core
+1! On Mon, Oct 06 2014, Zane Bitter wrote: > I'd like to propose that we add Pavlo Shchelokovskyy to the heat-core team. > > Pavlo has been a consistently active member of the Heat community - > he's a regular participant in IRC and at meetings, has been making > plenty of good commits[1] and maintains a very respectable review > rate[2] with helpful comments. I think he's built up enough experience > with the code base to be ready for core. > > Heat-cores, please vote by replying to this thread. As a reminder of > your options[3], +1 votes from 5 cores is sufficient; a -1 is treated > as a veto. > > cheers, > Zane. > > [1] > https://review.openstack.org/#/q/owner:%22Pavlo+Shchelokovskyy%22+status:merged+project:openstack/heat,n,z > [2] http://russellbryant.net/openstack-stats/heat-reviewers-30.txt > [3] https://wiki.openstack.org/wiki/Heat/CoreTeam#Adding_or_Removing_Members > > ___ > 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] [all][specs] Please stop doing specs for any changes in projects
I meant the administrative overhead of the contributor having to submit a spec to Gerrit and then everyone having to deal with yet another review, not the overhead of writing/reviewing the spec itself. On Tue, Jul 01 2014, Dolph Mathews wrote: > The argument has been made in the past that small features will require > correspondingly small specs. If there's a counter-argument to this example > (a "small" feature requiring a relatively large amount of spec effort), I'd > love to have links to both the spec and the resulting implementation so we > can discuss exactly why the spec was an unnecessary additional effort. > > On Tue, Jul 1, 2014 at 10:30 AM, Jason Dunsmore < > jason.dunsm...@rackspace.com> wrote: > >> On Mon, Jun 30 2014, Joshua Harlow wrote: >> >> > There is a balance here that needs to be worked out and I've seen >> > specs start to turn into requirements for every single patch (even if >> > the patch is pretty small). I hope we can rework the 'balance in the >> > force' to avoid being so strict that every little thing requires a >> > spec. This will not end well for us as a community. >> > >> > How have others thought the spec process has worked out so far? To >> > much overhead, to little…? >> > >> > I personally am of the opinion that specs should be used for large >> > topics (defining large is of course arbitrary); and I hope we find the >> > right balance to avoid scaring everyone away from working with >> > openstack. Maybe all of this is part of openstack maturing, I'm not >> > sure, but it'd be great if we could have some guidelines around when >> > is a spec needed and when isn't it and take it into consideration when >> > requesting a spec that the person you have requested may get >> > frustrated and just leave the community (and we must not have this >> > happen) if you ask for it without explaining why and how clearly. >> >> +1 I think specs are too much overhead for small features. A set of >> guidelines about when specs are needed would be sufficient. Leave the >> option about when to submit a design vs. when to submit code to the >> contributor. >> >> Jason >> >> ___ >> 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects
On Mon, Jun 30 2014, Joshua Harlow wrote: > There is a balance here that needs to be worked out and I've seen > specs start to turn into requirements for every single patch (even if > the patch is pretty small). I hope we can rework the 'balance in the > force' to avoid being so strict that every little thing requires a > spec. This will not end well for us as a community. > > How have others thought the spec process has worked out so far? To > much overhead, to little…? > > I personally am of the opinion that specs should be used for large > topics (defining large is of course arbitrary); and I hope we find the > right balance to avoid scaring everyone away from working with > openstack. Maybe all of this is part of openstack maturing, I'm not > sure, but it'd be great if we could have some guidelines around when > is a spec needed and when isn't it and take it into consideration when > requesting a spec that the person you have requested may get > frustrated and just leave the community (and we must not have this > happen) if you ask for it without explaining why and how clearly. +1 I think specs are too much overhead for small features. A set of guidelines about when specs are needed would be sufficient. Leave the option about when to submit a design vs. when to submit code to the contributor. Jason ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] [neutron] [trove] [swift] Uniform name for logger in projects
(Adding relevant projects to subject. Hope I didn't miss any.) Heat, Neutron, Trove, and Swift devs, Do we want to change all instances of "logger" variable names to "LOG" (like most OpenStack projects use) and enforce that via the hacking rules? Regards, Jason On Wed, May 21 2014, Sergey Kraynev wrote: > Hello, community. > > I hope, that most of your know, that a bug with name "Log debugs should not > have translations" (f.e. [1], [2], [3]) was recently raised in several > projects. The reason for this work is related with the following concerns > [4]. > There is a special check that is used (or will be used in some projects, > where the related patches have not merged yet) for verification process > (f.e. [5] or [6]). As you can see, this ([5]) verification uses the LOG > name of logger in regexp and "if" cases. > However, there are a lot of projects where both names "LOG" and "logger" > are used [7]. > So I have a question about the current situation: > - Should we use one uniform name for logger or add support for both names > in checks? > > In my opinion, declaration of one uniform name in hacking rules is > preferable, because it cleans code from useless duplicate names of one > variable and allows to create one uniform check for this rule. > > [1] https://bugs.launchpad.net/neutron/+bug/1320867 > [2] https://bugs.launchpad.net/swift/+bug/1318333 > [3] https://bugs.launchpad.net/oslo/+bug/1317950 > [4] https://wiki.openstack.org/wiki/LoggingStandards#Log_Translation > [5] > https://github.com/openstack/nova/blob/master/nova/hacking/checks.py#L201 > [6] https://review.openstack.org/#/c/94255/11/heat/hacking/checks.py > [7] https://github.com/openstack/heat/search?q=getLogger&type=Code > > Regards, > Sergey. > ___ > 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] [Heat] Proposing Thomas Spatzier for heat-core
+1 On Tue, Apr 22 2014, Steven Dake wrote: > HOT seemed like a job for Ethan Hunt. > > Nice work on finishing the job! > > big +1 from me > > > On 04/22/2014 11:43 AM, Zane Bitter wrote: >> Resending with [Heat] in the subject line. My bad. >> >> On 22/04/14 14:21, Zane Bitter wrote: >>> I'd like to propose that we add Thomas Spatzier to the heat-core team. >>> >>> Thomas has been involved in and consistently contributing to the Heat >>> community for around a year, since the time of the Havana design summit. >>> His code reviews are of extremely high quality IMO, and he has been >>> reviewing at a rate consistent with a member of the core team[1]. >>> >>> One thing worth addressing is that Thomas has only recently started >>> expanding the focus of his reviews from HOT-related changes out into the >>> rest of the code base. I don't see this as an obstacle - nobody is >>> familiar with *all* of the code, and we trust core reviewers to know >>> when we are qualified to give +2 and when we should limit ourselves to >>> +1 - and as far as I know nobody else is bothered either. However, if >>> you have strong feelings on this subject nobody will take it personally >>> if you speak up :) >>> >>> Heat Core team members, please vote on this thread. A quick reminder of >>> your options[2]: >>> +1 - five of these are sufficient for acceptance >>> 0 - abstention is always an option >>> -1 - this acts as a veto >>> >>> cheers, >>> Zane. >>> >>> >>> [1] http://russellbryant.net/openstack-stats/heat-reviewers-30.txt >>> [2] >>> https://wiki.openstack.org/wiki/Heat/CoreTeam#Adding_or_Removing_Members >>> >>> ___ >>> 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 > > > ___ > 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] User mailing lists for OpenStack projects
Here is the mailing list for openstack usage questions (for all projects): http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack On Thu, Mar 20 2014, Shaunak Kashyap wrote: > Hi folks, > > I am relatively new to OpenStack development as one of the developers > on the unified PHP SDK for OpenStack [1]. > > We were recently discussing about a mailing list for the users of this > SDK (as opposed to it’s contributors who will use openstack-dev@). The > purpose of such as mailing list would be for users of the SDK to > communicate with the contributors as well as each other. Of course, > there would be other avenues for such communication as well (IRC, for > instance). > > Specifically, we would like to know whether existing OpenStack > projects have mailing lists for their users and, if so, where they are > being hosted. > > Thanks, > > Shaunak > > [1] https://wiki.openstack.org/wiki/OpenStack-SDK-PHP > ___ > 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] [Heat] Resource dependencies
This is what you're looking for: http://docs.openstack.org/developer/heat/glossary.html#term-dependency On Thu, Mar 20 2014, Shaunak Kashyap wrote: > Hi, > > In a Heat template, what does it mean for a resource to depend on > another resource? As in, what is the impact of creating a dependency? > > I read > http://docs.openstack.org/developer/heat/template_guide/hot_spec.html#resources-section > and found this definition of the “depends_on” attribute: > >> This optional attribute allows for specifying dependencies of the > current resource on one or more other resources. Please refer to > section hot_spec_resources_dependencies for details. > > > Unfortunately, I can’t seem to find the referenced > “hot_spec_resources_dependencies” section anywhere. > > Thank you, > > Shaunak > ___ > 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] testr help
On Wed, Mar 12 2014, John Dennis wrote:
> On 03/12/2014 01:22 PM, Zane Bitter wrote:
>> On 10/03/14 20:29, Robert Collins wrote:
>>> Which bits look raw? It should only show text/* attachments, non-text
>>> should be named but not dumped.
>>
>> I was thinking of the:
>>
>> pythonlogging:'': {{{
>>
>> part.
>
> Yes, this is the primary culprit, it's output obscures most everything
> else concerning test results. Sometimes it's essential information.
> Therefore you should be able to control whether it's displayed or not.
The pythonlogging section didn't used to be so verbose, at least for
Heat's unit tests. I submitted 3 bugs to clean up the test output a few
weeks ago:
https://bugs.launchpad.net/heat/+bug/1281226
https://bugs.launchpad.net/oslo/+bug/1280454
https://bugs.launchpad.net/oslo/+bug/1280435
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] Nominate Jason Dunsmore for heat-core
Thanks everyone. It's an honor to join the team. I'm looking forward to meeting you all in Atlanta. On Mon, Feb 10 2014, Jeff Peeler wrote: > On Mon, Feb 10, 2014 at 11:38:40AM +1300, Steve Baker wrote: >> I would like to nominate Jason Dunsmore for heat-core. >> >> His reviews are valuable and prolific, his code contributions have >> demonstrated a good knowledge of heat internals, and he has endured a >> sound hazing to get multi-engine into heat. >> >> http://russellbryant.net/openstack-stats/heat-reviewers-60.txt >> http://www.stackalytics.com/?release=icehouse&metric=commits&user_id=jasondunsmore >> >> Heat cores, please reply with your vote. > > +1! > > ___ > 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] [heat][horizon]Heat UI related requirements & roadmap
On Wed, Nov 27 2013, Zane Bitter wrote: >> >> Parameters: >> db_name: >> group: db >> order: 0 >> db_username: >> group: db >> order: 1 >> db_password: >> group: db >> order: 2 >> web_node_name: >> group: web_node >> order: 0 >> keypair: >> group: web_node >> order: 1 > > -2 this is horrible. > > Imagine how much work this is for the poor author! At least they don't > have to maintain parallel hierarchies of matching key names like in > the original proposal, but they still have to manually maintain > multiple lists of orderings. What if you wanted to add another > parameter at the beginning? Maybe we should encourage authors to > number parameters with multiples of 10. Like BASIC programmers in the > 80s. > > And of course if you don't specify the order explicitly then you get > random order again. Sigh. > > There's only one way that this is even remotely maintainable for a > template author, and that's if they group and order stuff manually > anyway (like you have in your example - people will do this > automatically by themselves even if the syntax doesn't require them > to). Since they have to do this, just display the parameters in the UI > in the same order that they are defined in the file. This does the > Right Thing even if the author doesn't know about it, unlike the > explicit order thing which completely breaks down if the order is not > explicitly stated. You probably won't even have to document it because > literally 100% of people will either (a) not care, or (b) expect it to > work that way anyway. In fact, you will almost certainly get bug > reports if you don't display them in the same order as written. +1 for implicit ordering. I think this will be intuitive for users. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum/Heat] Is Solum really necessary?
Great description of Heat vs. Solum! This belongs in the FAQs of both projects IMO. This question is bound to keep coming up (for good reason). On Thu, Nov 14 2013, Angus Salkeld wrote: > On 14/11/13 13:41 -0500, Jay Pipes wrote: >>So while I have been on vacation, I've been thinking about Solum and Heat. >> >> And I have some lingering questions in my mind that make me question >> whether a new server project is actually necessary at all, and >> whether we really should just be targeting innovation and resources >> towards the Heat project. >> >> What exactly is Solum's API going to control that is not already >> represented in Heat's API and the HOT templating language? At this >> point, I'm really not sure, and I'm hoping that we can discuss this >> important topic before going any further with Solum. Right now, I >> see so much overlap that I'm questioning where the differences >> really are. >> >>Thoughts? > > I am very happy with how other projects have built on top > of heat. I think one reason this happens is Heat is trying > to focus on one main problem - Orchestrating restful resources. > > If we stick to this (and we are not overly opinionated) this > fosters other projects to develop on top. If we were in > a situation where Heat included solum's features it might > hinder Heat's adoption for other usecases. > > To me solum brings an opionated view to the world where > there is a specific way of creating/managing applications/services > that may not appeal to everyone. Hopefully it will apeal > to lots though! (just a particular user). > > One of Heat's main jobs is to make developing projects like solum, > tuskar, tripleO, trove & xlcloud easier to implement. > > And these projects will encourage more exciting projects further > up the stack. The further up the stack we go the more inovation > we can inspire. It all starts with building reliable simple > building blocks that can be easily used. > > > -Angus > >>-jay >> >>___ >>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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Multi-engine design feedback requested
Heat devs, There's been some good discussion on the Etherpad: https://etherpad.openstack.org/vJKcZcQOU9 I've added a "Votes" section under alternate options 1-5. Please read over the discussion and add your vote. Thanks, Jason On Thu, Aug 29 2013, Jason Dunsmore wrote: > Heat devs, > > Liang pointed out a race-condition in the current multi-engine > implementation that will be difficult to fix without a DB lock. I've > discussed the multi-engine design with my teammates and written up a few > alternative designs here: > https://etherpad.openstack.org/vJKcZcQOU9 > > Every design has its own downsides, so I was hoping to get some feedback > from the core devs as to which one is preferable. > > Feel free to add comments in-line. Please don't click "Clear Authorship > Colors" ;) > > Thanks, > Jason > > ___ > 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
[openstack-dev] [Heat] Multi-engine design feedback requested
Heat devs, Liang pointed out a race-condition in the current multi-engine implementation that will be difficult to fix without a DB lock. I've discussed the multi-engine design with my teammates and written up a few alternative designs here: https://etherpad.openstack.org/vJKcZcQOU9 Every design has its own downsides, so I was hoping to get some feedback from the core devs as to which one is preferable. Feel free to add comments in-line. Please don't click "Clear Authorship Colors" ;) Thanks, Jason ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Heat] Unique vs. non-unique stack names
Hello Heat devs, I've started doing some testing to find multi-engine bugs, and I discovered that it's possible to create two stacks with the same name when only a single heat-engine is running. Here are the results of my tests: http://dunsmor.com/heat/multi-engine.html#sec-1-1 Before I create a bug report about this, is it even necessary to enforce unique stack names within a tenant? Why don't we just key off of the stack ID when possible and throw an error when it's not possible to look up the stack by name? This is how novaclient does it. $ nova image-show F17_test ERROR: Multiple image matches found for 'F17_test', use an ID to be more specific. Regards, Jason ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
