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 YalagandulaSent: 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 thiruveedulaSent: 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 KraynevSent: 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=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-groupmetric=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
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=getLoggertype=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] [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] 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] 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=icehousemetric=commitsuser_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