Re: [openstack-dev] [Glare][Heat][TripleO] Heat artifact type

FWIW, option 2 is almost required unless we plan to be able to bundle multiple environments with a single template. While having a single environment for a single template can be useful, the even *more* useful scenario (and the primary one driving the development of environments initially) is wh

Re: [openstack-dev] [heat] upgrade options for custom heat resource plug-ins

releases? Do you just remove them at that point? If the > expected maximum lifespan of a stack is shorter than the span for which those > "deprecated" properties are maintained, then removing them works. But what > happens if it is longer? > > Cheers, > Praveen > >

Re: [openstack-dev] [heat] upgrade options for custom heat resource plug-ins

Not really. Ideally, you need to write your resource such that these changes are backwards compatible. We do this for the resources we ship with Heat (add new properties while supporting deprecated properties for several releases). On Apr 11, 2016, at 1:06 PM, "Praveen Yalagandula" wrote: > H

Re: [openstack-dev] [heat] Rico Lin for heat-core

+1 Original message From: Sergey Kraynev Date:12/07/2015 6:41 AM (GMT-06:00) To: "OpenStack Development Mailing List (not for usage questions)" Subject: [openstack-dev] [heat] Rico Lin for heat-core Hi all. I'd like to nominate Rico Lin for heat-core. He did awesome job with pr

Re: [openstack-dev] [Heat] publicURL vs internalURL for resource validation

This is a coin flip IMO. Heat can be deployed separately from other infrastructure. If this does change, I'd like to see a fail over mechanism in the client plugin mechanism that will switch to the public URL if it can't access the private one. Original message From: Matt Fis

Re: [openstack-dev] [Heat] core team nomination

+1 Original message From: Sergey Kraynev Date:10/20/2015 8:42 AM (GMT-06:00) 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 Razumovsk

Re: [openstack-dev] [Heat] creating a stack with a config_drive

The drive will contain the user data. Its an alternative to the metadata service and isn't a "normal" drive. Its created, mounted, and populated by Nova. Original message From: Maish Saidel-Keesing Date:08/07/2015 8:35 AM (GMT-06:00) To: Randall Burt ,

Re: [openstack-dev] [Heat] creating a stack with a config_drive

config_drive: true just tells the instance to mount the drive. You pass data via the user_data property. Original message From: Maish Saidel-Keesing Date:08/07/2015 8:08 AM (GMT-06:00) To: "OpenStack Development Mailing List (not for usage questions)" Subject: [openstack-dev] [H

Re: [openstack-dev] [Heat] [app-catalog] conditional resource exposure - second thoughts

tor easily know the users > actually need something they aren't providing gives them the opportunity to > fix the issue, benefiting all 3 parties. > > Thanks, > Kevin > > > From: Randall Burt [randall.b...@rackspace.com] > Sent: Tue

Re: [openstack-dev] [Heat] [app-catalog] conditional resource exposure - second thoughts

Making users complain to admins that may have little to no control over what is and isn't available isn't a healthy strategy for user experience. Purposefully engineering hardship to try and influence operators to "do the right thing" in someone else's opinion sounds pretty counter productive to

Re: [openstack-dev] [Heat] Show attribute is a collection of other attributes or not?

On Jul 2, 2015, at 2:35 PM, Steve Baker wrote: > On 03/07/15 06:03, Randall Burt wrote: >> Maybe use "all" for all attributes in the schema and use "show" for the raw >> output from the service (as is done today for server and neutron stuff). > Instead

Re: [openstack-dev] [Heat] Show attribute is a collection of other attributes or not?

Maybe use "all" for all attributes in the schema and use "show" for the raw output from the service (as is done today for server and neutron stuff). On Jul 2, 2015, at 12:46 PM, Steven Hardy wrote: > On Thu, Jul 02, 2015 at 04:40:49PM +0300, Sergey Kraynev wrote: >> Hi Heaters. >> I don't

Re: [openstack-dev] [Solum] [ Supporting swift downloads for operator languagepacks

, would it point to the source git repo > that Solum would use to generate the LP still? > > Thanks, > Kevin > > From: Randall Burt [randall.b...@rackspace.com] > Sent: Wednesday, June 17, 2015 11:38 AM > To: OpenStack Developmen

Re: [openstack-dev] [Solum] Supporting swift downloads for operator languagepacks

uld use swift client for both private > and public LP uses? That sounds like a good suggestion to me. > > Adrian > >> On Jun 17, 2015, at 11:10 AM, Randall Burt >> wrote: >> >> Can't an operator make the target container public therefore removing

Re: [openstack-dev] [Solum] Supporting swift downloads for operator languagepacks

Can't an operator make the target container public therefore removing the need for multiple access strategies? Original message From: Murali Allada Date:06/17/2015 11:41 AM (GMT-06:00) To: "OpenStack Development Mailing List (not for usage questions)" Subject: [openstack-dev] [S

Re: [openstack-dev] [Solum] Should logs be deleted when we delete an app?

While I agree with what you're saying, the way the OpenStack clients are traditionally written/designed, the CLI *is* the SDK for those users who want to do scripting in a shell rather than in Python. If we go with your suggestion, we'd probably also want to have the ability to suppress those p

Re: [openstack-dev] [Solum] Should logs be deleted when we delete an app?

+1 Murali. AFIAK, there is no precedent for what Keith proposes, but that doesn't mean its a bad thing. On Jun 16, 2015, at 12:21 AM, Murali Allada wrote: > I agree, users should have a mechanism to keep logs around. > > I implemented the logs deletion feature after we got a bunch of requests

Re: [openstack-dev] COMMERCIAL: [heat] Stack/Resource updated_at conventions

2 sounds right to me, but does the in-memory representation get updated or are we forced into a refetch at every change? On Apr 27, 2015, at 10:46 AM, Steven Hardy wrote: > Hi all, > > I've been looking into $subject recently, I raised this bug: > > https://bugs.launchpad.net/heat/+bug/144815

Re: [openstack-dev] [Heat] Stepping down from core

Sorry to see you go. Thanks so much for your contribution and best of luck on your new project! On Feb 27, 2015, at 2:23 PM, Jeff Peeler wrote: > As discussed during the previous Heat meeting, I'm going to be stepping down > from core on the Heat project. My day to day focus is going to be mo

Re: [openstack-dev] [Heat] core team changes

+1 On Jan 27, 2015, at 7:36 PM, 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: >

Re: [openstack-dev] [Heat] How can I write at milestone section of blueprint?

Its been discussed at several summits. We have settled on a general solution using Zaqar, but no work has been done that I know of. I was just pointing out that similar blueprints/specs exist and you may want to look through those to get some ideas about writing your own and/or basing your propo

Re: [openstack-dev] [Heat] How can I write at milestone section of blueprint?

There should already be blueprints in launchpad for very similar functionality. For example: https://blueprints.launchpad.net/heat/+spec/lifecycle-callbacks. While that specifies Heat sending notifications to the outside world, there has been discussion around debugging that would allow the rece

Re: [openstack-dev] [Heat] Rework auto-scaling support in Heat

Per our discussion in Paris, I'm partial to Option B. I think a separate API endpoint is a lower priority at this point compared to cleaning up and normalizing the autoscale code on the back-end. Once we've refactored the engine code and solidified the RPC interface, it would be trivial to add a

Re: [openstack-dev] [Heat] Conditionals, was: New function: first_nonnull

On Nov 12, 2014, at 10:42 AM, Zane Bitter wrote: > On 12/11/14 10:10, Clint Byrum wrote: >> Excerpts from Zane Bitter's message of 2014-11-11 13:06:17 -0800: >>> On 11/11/14 13:34, Ryan Brown wrote: I am strongly against allowing arbitrary Javascript functions for complexity reasons. I

Re: [openstack-dev] [Heat] Conditionals, was: New function: first_nonnull

I like this approach and seems to have greater utility beyond the original proposal. I'm not fussed on YAQL or straight up JSONPath, but something along those lines seems to make sense. On Nov 11, 2014, at 9:35 AM, Alexis Lee wrote: > Alexis Lee said on Mon, Nov 10, 2014 at 05:34:13PM +:

Re: [openstack-dev] [Heat] stevedore plugins (and wait conditions)

On Jul 10, 2014, at 9:21 AM, Zane Bitter wrote: > On 10/07/14 05:34, Steven Hardy wrote: > >The other approach is to set up a new container, owned by the user, > >every time. In that case, a provider selecting this implementation > >would need to make it clear to customers if th

Re: [openstack-dev] [Heat] stevedore plugins (and wait conditions)

On Jul 9, 2014, at 4:38 PM, Zane Bitter wrote: > On 08/07/14 17:17, Steven Hardy wrote: > >> Regarding forcing deployers to make a one-time decision, I have a question >> re cost (money and performance) of the Swift approach vs just hitting the >> Heat API >> >> - If folks use the Swift resourc

Re: [openstack-dev] [Heat] stevedore plugins (and wait conditions)

On Jul 9, 2014, at 3:15 PM, Zane Bitter wrote: > On 08/07/14 17:13, Angus Salkeld wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 08/07/14 09:14, Zane Bitter wrote: >>> I see that the new client plugins are loaded using stevedore, which is >>> great and IMO absolutely the ri

Re: [openstack-dev] [Ceilometer] [Heat] Ceilometer aware people, please advise us on processing notifications..

On Jun 26, 2014, at 5:25 PM, Zane Bitter wrote: > On 23/06/14 19:25, Clint Byrum wrote: >> Hello! I would like to turn your attention to this specification draft >> that I've written: >> >> https://review.openstack.org/#/c/100012/1/specs/convergence-continuous-observer.rst >> >> Angus has sugg

Re: [openstack-dev] [heat] Sergey Kraynev for heat-core

On Jun 26, 2014, at 5:08 PM, Steve Baker wrote: > I'd like to nominate Sergey Kraynev for heat-core. His reviews are > valuable and prolific, and his commits have shown a sound understanding > of heat internals. > > http://stackalytics.com/report/contribution/heat-group/60 +1

Re: [openstack-dev] [Heat] fine grained quotas

On Jun 19, 2014, at 4:17 PM, Clint Byrum wrote: > I was made aware of the following blueprint today: > > http://blueprints.launchpad.net/heat/+spec/add-quota-api-for-heat > http://review.openstack.org/#/c/96696/14 > > Before this goes much further.. I want to suggest that this work be > cancell

Re: [openstack-dev] [HEAT] Discussion: How to list nested stack resources.

I've submitted the spec (finally) and will work on some initial patches this afternoon/tomorrow. Please provide any feedback and thanks! https://review.openstack.org/#/c/98219 On Jun 5, 2014, at 11:35 AM, Randall Burt wrote: > Hey, sorry for the slow follow. I have to put some f

Re: [openstack-dev] [HEAT] Discussion: How to list nested stack resources.

I have submitted a new/expanded spec for this feature: https://review.openstack.org/#/c/98219/. I hope to start some WiP patches this afternoon/tomorrow morning. Spec reviews and input most welcome. On Jun 5, 2014, at 11:35 AM, Randall Burt wrote: > Hey, sorry for the slow follow. I have

Re: [openstack-dev] [HEAT] Discussion: How to list nested stack resources.

ent call --nested (randall) > b) A flattened DS in the output (tim) > > > Thanks all ! > > > On Wed, May 21, 2014 at 12:42 AM, Randall Burt > wrote: > Bartosz, would that be in addition to --nested? Seems like id want to be able > to say "all of it"

Re: [openstack-dev] [Heat]Heat template parameters encryption

On Jun 4, 2014, at 7:30 PM, Clint Byrum wrote: > Excerpts from Randall Burt's message of 2014-06-04 17:17:07 -0700: >> On Jun 4, 2014, at 7:05 PM, Clint Byrum >> wrote: >> >>> Excerpts from Zane Bitter's message of 2014-06-04 16:19:05 -0700: On 04/06/14 15:58, Vijendar Komalla wrote:

Re: [openstack-dev] [Heat]Heat template parameters encryption

On Jun 4, 2014, at 7:05 PM, Clint Byrum wrote: > Excerpts from Zane Bitter's message of 2014-06-04 16:19:05 -0700: >> On 04/06/14 15:58, Vijendar Komalla wrote: >>> Hi Devs, >>> I have submitted an WIP review (https://review.openstack.org/#/c/97900/) >>> for Heat parameters encryption blueprint

Re: [openstack-dev] [solum] reviews for the new API

Sorry to poke my head in, but doesn't that beg the question of why you'd want to expose some third party DSL in the first place? If its an advanced feature, I wonder why it would be even considered before the 90% solution works, much less take a dependency on another non-integrated service. IMO,

[openstack-dev] [Barbican][Heat] Reviews requested for Barbican resources

Hello Barbican devs. I was wondering if we could get some of you to weigh in on a couple of reviews for adding Barbican support in Heat. We seem to be churning a bit around current and future features supported by the resources and could use some expert opinions. Blueprint: https://blueprints.l

Re: [openstack-dev] [HEAT] Discussion: How to list nested stack resources.

pad.net/heat/+spec/explode-nested-resources >> >> Spec: https://wiki.openstack.org/wiki/Heat/explode-resource-list >> >> Tim >> >> On 5/19/14 1:53 PM, "Tim Schnell" wrote: >> >>> On 5/19/14 12:35 PM, "Randall Burt" wrote: >

Re: [openstack-dev] [HEAT] Discussion: How to list nested stack resources.

On May 19, 2014, at 11:39 AM, Steven Hardy wrote: > On Mon, May 19, 2014 at 03:26:22PM +, Tim Schnell wrote: >> Hi Nilakhya, >> >> As Randall mentioned we did discuss this exact issue at the summit. I was >> planning on putting a blueprint together today to continue the discussion. >> The S

Re: [openstack-dev] [HEAT] Discussion: How to list nested stack resources.

Nilakhya, We discussed this a bit at the summit and I think the consensus was that this would be a good thing to do by passing a flag to resource-list that would "flatten" the structure of nested stacks in the call. Tim Schnell brought this up as well and may be interested in helping define the

Re: [openstack-dev] [heat] How to cross-reference resources within OS::Heat::ResourceGroup

to construct a reference to a > particular instance of, say, a port, when creating an instance of a > floating IP? > > On 5/6/14, 12:41 PM, "Randall Burt" wrote: > >> A resource group's definition contains only one resource and you seem to >> want groups

Re: [openstack-dev] [heat] How to cross-reference resources within OS::Heat::ResourceGroup

A resource group's definition contains only one resource and you seem to want groups of multiple resources. You would need to use a nested stack or provider template to do what you're proposing. On May 6, 2014, at 2:23 PM, "Janczuk, Tomasz" wrote: > I am trying to create an OS::Heat::Resource

Re: [openstack-dev] [Heat] Proposing Thomas Spatzier for heat-core

+1 On Apr 22, 2014, at 1:43 PM, 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 Hea

Re: [openstack-dev] [Heat] [Glance] How about managing heat template like flavors in nova?

We discussed this with the Glance community back in January and it was agreed that we should extend Glance's scope to include Heat templates as well as other artifacts. I'm planning on submitting some patches around this during Juno. Adding the Glance tag as this is relevant to them as well. -

Re: [openstack-dev] [heat] Custom Resource

On Apr 14, 2014, at 8:08 AM, Rabi Mishra wrote: > Hi Steve, > > Thanks a lot for your prompt response. I can't agree more that the CFN custom > resource implementation is complex with it's dependency on SNS and SQS. > However, it decouples the implementation of the resource life-cycle from

Re: [openstack-dev] [Heat] [TripleO] Better handling of lists in Heat - a proposal to add a map function

On Apr 4, 2014, at 1:56 PM, Zane Bitter wrote: > On 19/02/14 02:48, Clint Byrum wrote: >> Since picking up Heat and trying to think about how to express clusters >> of things, I've been troubled by how poorly the CFN language supports >> using lists. There has always been the Fn::Select functio

Re: [openstack-dev] [Heat][Murano][TOSCA] Murano team contrib. to Heat TOSCA activities

On Mar 10, 2014, at 1:26 PM, Georgy Okrokvertskhov wrote: > Hi, > > Thomas and Zane initiated a good discussion about Murano DSL and TOSCA > initiatives in Heat. I think will be beneficial for both teams to contribute > into TOSCA. Wasn't TOSCA developing a "simplified" version in order to

Re: [openstack-dev] [Heat] [TripleO] Better handling of lists in Heat - a proposal to add a map function

This may also be relevant: https://blueprints.launchpad.net/heat/+spec/override-resource-name-in-resource-group On Feb 19, 2014, at 1:48 AM, Clint Byrum wrote: > Since picking up Heat and trying to think about how to express clusters > of things, I've been troubled by how poorly the CFN langua

Re: [openstack-dev] [heat] Nominate Jason Dunsmore for heat-core

Very +1 Original message From: Steve Baker Date:02/09/2014 4:41 PM (GMT-06:00) To: OpenStack Development Mailing List Subject: [openstack-dev] [heat] Nominate Jason Dunsmore for heat-core I would like to nominate Jason Dunsmore for heat-core. His reviews are valuable and prolif

Re: [openstack-dev] [Heat] About LaunchConfiguration and Autoscaling

On Jan 30, 2014, at 12:09 PM, Clint Byrum wrote: > Excerpts from Zane Bitter's message of 2014-01-30 07:38:38 -0800: >> On 30/01/14 06:01, Thomas Herve wrote: >>> Hi all, >>> >>> While talking to Zane yesterday, he raised an interesting question about >>> whether or not we want to keep a Launc

Re: [openstack-dev] [heat] Nomination for heat-core

+1 Sent from my Verizon Wireless 4G LTE Smartphone Original message From: Steve Baker Date: 12/18/2013 8:28 PM (GMT-06:00) To: OpenStack Development Mailing List Subject: [openstack-dev] [heat] Nomination for heat-core I would like to nominate Bartosz Górski to be a heat-

Re: [openstack-dev] [heat] [glance] Heater Proposal

On Dec 11, 2013, at 5:44 PM, Georgy Okrokvertskhov wrote: > Hi, > > To keep this thread alive I would like to share the small screencast I've > recorded for Murano Metadata repository. I would like to share with you what > we have in Murano and start a conversation about metadata repository

Re: [openstack-dev] [heat] Stack preview

On Dec 10, 2013, at 3:46 PM, Zane Bitter wrote: > On 10/12/13 15:10, Randall Burt wrote: >> On Dec 10, 2013, at 1:27 PM, Zane Bitter >> wrote: >> >>> On 10/12/13 12:46, Richard Lee wrote: >>>> Hey all, >>>> >>>> We're w

Re: [openstack-dev] [heat] Stack convergence first steps

topher Armstrong mailto:chris.armstr...@rackspace.com>> wrote: > On Thu, Dec 5, 2013 at 7:25 PM, Randall Burt > mailto:randall.b...@rackspace.com>>wrote: > > > On Dec 5, 2013, at 6:25 PM, Christopher Armstrong < > > chris.armstr...@rackspace.com<mailto:chris.ar

Re: [openstack-dev] [heat] Stack preview

On Dec 10, 2013, at 1:27 PM, Zane Bitter wrote: > On 10/12/13 12:46, Richard Lee wrote: >> Hey all, >> >> We're working on a blueprint >> that adds >> the ability to preview what a given template+parameters would create in >> terms of

Re: [openstack-dev] [heat] [glance] Heater Proposal

On Dec 6, 2013, at 5:04 PM, Clint Byrum wrote: > Excerpts from Randall Burt's message of 2013-12-06 14:43:05 -0800: >> I too have warmed to this idea but wonder about the actual implementation >> around it. While I like where Edmund is going with this, I wonder if it >> wouldn't be valuable in

Re: [openstack-dev] [heat] [glance] Heater Proposal

I too have warmed to this idea but wonder about the actual implementation around it. While I like where Edmund is going with this, I wonder if it wouldn't be valuable in the short-to-mid-term (I/J) to just add /templates to Glance (/assemblies, /applications, etc) along side /images. Initially,

Re: [openstack-dev] [heat][horizon]Heat UI related requirements & roadmap

I hope I'm not re-opening worm cans here, and that's not my intent, but I just wanted to get a little clarification in-line below: On Dec 6, 2013, at 3:24 PM, Tim Schnell wrote: > To resolve this thread, I have created 5 blueprints based on this mailing > list discussion. I have attempted to d

Re: [openstack-dev] [heat] Stack convergence first steps

On Dec 5, 2013, at 6:25 PM, Christopher Armstrong mailto:chris.armstr...@rackspace.com>> wrote: On Thu, Dec 5, 2013 at 3:50 PM, Anderson Mesquita mailto:anderson...@thoughtworks.com>> wrote: Hey stackers, We've been working towards making stack convergence (https://blueprints.launchpad.net/he

Re: [openstack-dev] [heat] [glance] Heater Proposal

On Dec 5, 2013, at 4:45 PM, Steve Baker mailto:sba...@redhat.com>> wrote: On 12/06/2013 10:46 AM, Mark Washenberger wrote: On Thu, Dec 5, 2013 at 1:05 PM, Vishvananda Ishaya mailto:vishvana...@gmail.com>> wrote: On Dec 5, 2013, at 12:42 PM, Andrew Plunk mailto:andrew.pl...@rackspace.com>>

Re: [openstack-dev] [heat] Heater Proposal

On Dec 5, 2013, at 4:08 PM, Georgy Okrokvertskhov mailto:gokrokvertsk...@mirantis.com>> wrote: Hi, I am really glad to see the line of thinking close to what we at Murano see as a right direction for OpenStack development. This is a good initiative which potentially will be useful for other p

Re: [openstack-dev] [heat] [glance] Heater Proposal

On Dec 5, 2013, at 11:10 AM, Clint Byrum wrote: > Excerpts from James Slagle's message of 2013-12-05 08:35:12 -0800: >> On Thu, Dec 5, 2013 at 11:10 AM, Clint Byrum wrote: >>> Excerpts from Monty Taylor's message of 2013-12-04 17:54:45 -0800: Why not just use glance? >>> >>> I've as

Re: [openstack-dev] [heat] [glance] Heater Proposal

On Dec 5, 2013, at 10:10 AM, Clint Byrum wrote: > Excerpts from Monty Taylor's message of 2013-12-04 17:54:45 -0800: >> Why not just use glance? >> > > I've asked that question a few times, and I think I can collate the > responses I've received below. I think enhancing glance to do these > th

Re: [openstack-dev] [Solum] CLI minimal implementation

I disagree. If a param is required and has no meaningful default, it should be positional IMO. I think this actually reduces confusion as you can tell from the signature alone that this is a value the user must supply to have any meaningful thing happen. On Dec 3, 2013, at 10:13 AM, Paul Montgo

Re: [openstack-dev] [Heat] rough draft of Heat autoscaling API

On Nov 14, 2013, at 1:05 PM, Christopher Armstrong mailto:chris.armstr...@rackspace.com>> wrote: On Thu, Nov 14, 2013 at 11:00 AM, Randall Burt mailto:randall.b...@rackspace.com>> wrote: On Nov 14, 2013, at 12:44 PM, Zane Bitter mailto:zbit...@redhat.com>> wrote: &

Re: [openstack-dev] [Heat] rough draft of Heat autoscaling API

On Nov 14, 2013, at 12:44 PM, Zane Bitter wrote: > On 14/11/13 18:51, Randall Burt wrote: >> >> On Nov 14, 2013, at 11:30 AM, Christopher Armstrong >> mailto:chris.armstr...@rackspace.com>> >> wrote: >> >>> On Thu, Nov 14, 2013 at 11:16 AM, Ra

Re: [openstack-dev] [Heat] rough draft of Heat autoscaling API

On Nov 14, 2013, at 11:30 AM, Christopher Armstrong mailto:chris.armstr...@rackspace.com>> wrote: On Thu, Nov 14, 2013 at 11:16 AM, Randall Burt mailto:randall.b...@rackspace.com>> wrote: Good stuff! Some questions/comments: If web hooks are associated with policies and

Re: [openstack-dev] [Heat] rough draft of Heat autoscaling API

down, I think the response should be something like 307 if the hook is on cool down with an appropriate retry-after header. On Nov 14, 2013, at 10:57 AM, Randall Burt mailto:randall.b...@rackspace.com>> wrote: On Nov 14, 2013, at 10:19 AM, Christopher Armstrong mailto:chris.

Re: [openstack-dev] [Heat] rough draft of Heat autoscaling API

On Nov 14, 2013, at 10:19 AM, Christopher Armstrong mailto:chris.armstr...@rackspace.com>> wrote: http://docs.heatautoscale.apiary.io/ I've thrown together a rough sketch of the proposed API for autoscaling. It's written in API-Blueprint format (which is a simple subset of Markdown) and prov

Re: [openstack-dev] [Heat] Do we need to clean up resource_id after deletion?

My thoughts exactly. I meant to dig into the soft-delete code to see if those changes handled resource_id differently but I got to traveling and forgot. IMO, if it universally needs doing, then it should be done in resource.Resource and be cognizant of deletion policy. __

Re: [openstack-dev] [heat] Proposal for new heat-core member

Thanks all. I'm honored to join this great team! Original message From: Steve Baker Date: 10/29/2013 3:24 PM (GMT-06:00) To: openstack-dev@lists.openstack.org Cc: Randall Burt Subject: Re: [openstack-dev] [heat] Proposal for new heat-core member I count enough cor

Re: [openstack-dev] [Heat] Comments on Steve Baker's Proposal on HOT Software Config

On Oct 28, 2013, at 9:49 AM, Steven Hardy wrote: > On Mon, Oct 28, 2013 at 02:33:40PM +0000, Randall Burt wrote: >> >> On Oct 28, 2013, at 8:53 AM, Steven Hardy >> wrote: >> >>> On Sun, Oct 27, 2013 at 11:23:20PM -0400, Lakshminaraya Renganarayana wrote

Re: [openstack-dev] [Heat] Comments on Steve Baker's Proposal on HOT Software Config

On Oct 28, 2013, at 8:53 AM, Steven Hardy wrote: > On Sun, Oct 27, 2013 at 11:23:20PM -0400, Lakshminaraya Renganarayana wrote: >> A few us at IBM studied Steve Baker's proposal on HOT Software >> Configuration. Overall the proposed constructs and syntax are great -- we >> really like the clean

Re: [openstack-dev] [Heat] Network topologies [and more]

On Oct 28, 2013, at 9:07 AM, Mike Spreitzer mailto:mspre...@us.ibm.com>> wrote: Zane Bitter mailto:zbit...@redhat.com>> wrote on 10/28/2013 06:47:50 AM: > On 27/10/13 16:37, Edgar Magana wrote: > > Heat Developers, > > > > I am one of the core developers for Neutron who is lately working on th

Re: [openstack-dev] [Heat] How the autoscale API should control scaling in Heat

On Aug 15, 2013, at 6:20 PM, Angus Salkeld wrote: > On 15/08/13 17:50 -0500, Christopher Armstrong wrote: >> *Introduction and Requirements* >> >> So there's kind of a perfect storm happening around autoscaling in Heat >> right now. It's making it really hard to figure out how I should compose

Re: [openstack-dev] [Heat] Multi region support for Heat

On Jul 23, 2013, at 11:03 AM, Clint Byrum wrote: > Excerpts from Steve Baker's message of 2013-07-22 21:43:05 -0700: >> On 07/23/2013 10:46 AM, Angus Salkeld wrote: >>> On 22/07/13 16:52 +0200, Bartosz Górski wrote: Hi folks, I would like to start a discussion about the blueprin