20:00:04 <shardy> #startmeeting heat
20:00:05 <openstack> Meeting started Wed May 15 20:00:04 2013 UTC.  The chair is shardy. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:08 <openstack> The meeting name has been set to 'heat'
20:00:14 <shardy> #topic rollcall
20:00:23 <stevebaker_> holla
20:00:24 <randallburt> hello all
20:00:25 <zaneb> howdy
20:00:28 <pfreund> hi
20:00:28 <hanney> hi all
20:00:30 <shardy> shardy here
20:00:36 <therve> Hi!
20:00:37 <SpamapS> o/
20:00:38 <sdake> o/
20:00:50 <alexheneveld> hello
20:00:55 <jpeeler> hey
20:01:17 <shardy> asalkeld around?
20:01:44 <shardy> #topic Review last week's actions
20:01:49 <asalkeld> hi
20:01:56 <asalkeld> sorry bit late
20:02:16 <shardy> hey asalkeld
20:02:20 <wirehead_> heya
20:02:22 <shardy> #info stevebaker to send ML email re backwards-compatibility
20:02:31 <shardy> stevebaker: did that happen?
20:02:36 <stevebaker_> It appears that I haven't written that email yet. Please add it as an action again
20:02:43 <shardy> Ok, np
20:02:55 <shardy> #action stevebaker stevebaker to send ML email re backwards-compatibility
20:03:08 <shardy> #info all to look at dsl examples and provide feedback
20:03:30 <randallburt> that's been done some, but more review would be greatly appreciated.
20:03:47 <shardy> So I know the DSL discussions are ongoing, but anyone got any specific comments or requests in that area?
20:03:55 <wirehead_> yeah, I've not made any comments, but I've been looking at 'em and pondering
20:03:58 <randallburt> we also had a discussion today about merging some proposals and pushing hard on getting a "fina" single wordpress template sorted.
20:04:25 <shardy> I've agreed to post a PoC patch showing how we could possibly do an engine level translation from the proposed HOT format to the internal model
20:04:38 <randallburt> maybe an action for me and Thomas to get that done soonest?
20:04:41 <shardy> I'll post a draft/wip patch so we can all comment
20:04:47 <shardy> hopefully by next week
20:05:01 <shardy> #action shardy PoC HOT patch
20:05:10 <randallburt> shardy: I'm still green in that area, but let me know how/if I can help
20:05:42 <shardy> and as randallburt said, we're pushing for a consensus on a basic template to test with
20:05:43 <zaneb> is there a reason we're trying to adapt our internal model to the template format and not the other way around?
20:06:17 <shardy> #action randallburt, tspatzier provide converged DSL/HOT example
20:06:41 <SpamapS> zaneb: because our current internal model lacks some capabilities that are desired
20:07:06 <asalkeld> also it's based on aws
20:07:08 <randallburt> zaneb: and we hope it will be additive and (relatively) transparent to the CFN
20:07:11 <shardy> zaneb: that's a good question - my understanding is we're trying to identify the gaps in the internal model
20:07:14 <zaneb> SpamapS: oh, I know that
20:07:24 <zaneb> randallburt: +1
20:07:50 <randallburt> *hope* ;)
20:07:57 <SpamapS> I mostly see there just being some new internal resources and a few things abstracted so that both cfn and HOT can use them in slightly different ways.
20:07:58 <alexheneveld> ideally CFN can inject into HOT but HOT will be easier to use and more powerful
20:08:02 <shardy> zaneb: I see the template-syntax thing as being a byproduct of the process, really it's a way for us to hack on the abstractions IMO
20:08:14 <tspatzier> zaneb: I think the plan would not be to change the internal model radically for this first HOT patch, but let it evolve over time, basically to enrich it for new features as randallburt and SpamapS said
20:08:37 <zaneb> tspatzier: agree with that
20:08:50 <shardy> Yep, and to figure out where/how we can do that in a low-risk way
20:09:05 <zaneb> just concerned that starting top-down with the format and then trying to squeeze that into an implementation is making life hard for ourselves
20:09:07 <shardy> which is the point of us starting to look at how we can do that with some code
20:09:19 <SpamapS> If there's something to spend time on now, it is making sure HOT is forward-flexible so whatever we support in the first release we can keep supporting for a long time.
20:09:19 <alexheneveld> composability and substitutability let people do cool things, and safe if we can do it incrementally which is the plan
20:09:29 <randallburt> zaneb: yeah, why we hope to put some code to it soonest
20:09:32 <shardy> zaneb: I'm hoping when we start actually looking at code the process may reverse somewhat
20:09:52 <zaneb> ok
20:09:56 <zaneb> moving on
20:10:01 <m4dcoder> is there a place that describe this HOT format for new folks like me to catch up?
20:10:03 <tspatzier> I think getting something concrete started comming from bottom up can help to shape the DSL instead of just doing conceptual work for too long
20:10:05 <shardy> ie we'll figure out the gaps, add stuff, then work out a sane way to expose it via templates
20:10:28 <shardy> #link https://review.openstack.org/28598
20:10:35 <shardy> m4dcoder: ^^
20:10:39 <randallburt> m4dcoder:  not yet, but would be a good idea as we validate the simple templates before moving on to more complex stuffs
20:11:00 <shardy> ok, lets move on shall we?
20:11:07 <randallburt> +q
20:11:10 <shardy> #topic Reorganize resources into heat/engine/resources/OS, heat/engine/resources/AWS
20:11:12 <randallburt> or 1 rather
20:11:40 <sdake> this came out of a irc chat spamaps and I had last week
20:11:54 <shardy> Sounds like a good idea
20:12:08 <randallburt> is this the "Taking the AWS out of Heat"?
20:12:11 <shardy> zaneb: will it be a problem for the plugin code?
20:12:12 <SpamapS> Indeed
20:12:15 <zaneb> one issue with this
20:12:26 <zaneb> some of the code is shared
20:12:38 <stevebaker_> I think that is a great idea, but how to handle volume.py, which now has both AWS::EC2::Volume and native cinder resource type?
20:12:39 <SpamapS> I was thinking there would also be a common?
20:12:41 <zaneb> e.g. CinderVolume inherits from Volume (the AWS one)
20:12:49 <sdake> probably break them up
20:12:51 <therve> zaneb, I started working on changing that
20:13:15 <shardy> Yeah, we should still have common base classes where it makes sense to, or modify the AWS resources to inherit and override stuff from the native ones
20:13:16 <zaneb> we could have a common base or something
20:13:20 <therve> Creating utility functions instead of inheritance
20:13:24 <sdake> so spamaps and I had this discussion about inheritance as well
20:13:35 <therve> It adds a tiny bit of duplication that we can leave with I think
20:13:41 <asalkeld> Is this bringing any value?
20:13:50 <zaneb> asalkeld: +1 exactly
20:13:54 <sdake> and we both agreed we dislike that model :)  which is why this was added to the agenda so people could vote on whether we really want inheritance in resources or not
20:14:00 <SpamapS> Yes it brings the ability to turn off AWS
20:14:04 <asalkeld> isn't there heaps of bp we could be working on?
20:14:05 <SpamapS> which is desired by deployers
20:14:13 <stevebaker_> can we have pythonic package names? heat.engine.resources.aws.ec2.volume
20:14:21 <SpamapS> stevebaker_: +1
20:14:23 <zaneb> SpamapS: how? by deleting all the python files?
20:14:24 <asalkeld> filter by not 'AWS::'
20:14:35 <zaneb> asalkeld: yes, exactly
20:14:47 <sdake> asalkeld if there are bps you want to work on work on them
20:14:50 <SpamapS> Thats a fair point.
20:14:57 <zaneb> the way to turn off aws is to filter out all plugins that start with AWS:: at registration time
20:15:05 <sdake> this came out of the original native server resource
20:15:29 <asalkeld> so but it is not strictly neccessary
20:15:30 <sdake> which lists inheritence as a goal
20:15:38 <asalkeld> (move the code about)
20:16:05 <stevebaker_> is anybody against reorganizing python classes to match resource type names?
20:16:25 <SpamapS> Hm
20:16:29 <zaneb> filter = 1 line in config file, vs. selectively installing modules
20:16:44 <sdake> zaneb those are orthogonal
20:16:47 <shardy> I think there are advantages long term (assuming we're aiming to have a full set of native resources) in having the AWS ones inherit/share implementation
20:16:59 <SpamapS> zaneb: I didn't mean by selectively installing modules, I was more thinking of abstraction to make it clear where AWS specific things were happening.
20:17:03 <sdake> zaneb: you could still install AWS resources, just not enable them
20:17:10 <SpamapS> zaneb: but the filter is superior, so I like that better.
20:17:14 <stevebaker_> shardy: they could do that and still be in separate files though
20:17:28 <sdake> clearly we want to filter, but also putting them in different places makes the code more sanitary
20:17:35 <shardy> stevebaker_: Yes, agreed
20:17:49 <SpamapS> I am -1 on inheriting from native resources being the way they work, but +1 for filtering.
20:17:51 <shardy> I guess this is really part of the abstract-aws BP?
20:18:04 <shardy> #link https://blueprints.launchpad.net/heat/+spec/abstract-aws
20:18:07 <zaneb> I'm not against better code organisation
20:18:27 <zaneb> but as a development priority... it isn't even on the list
20:18:29 <sdake> i am -1 on inheriting too - inheritance evil
20:18:36 <SpamapS> The point is simply to be able to document/use/deploy Heat w/o the AWS
20:18:38 <stevebaker_> anyone volunteering for the reorg?
20:18:42 <sdake> zaneb it is in grizzly-2
20:18:50 <SpamapS> abstract-aws doesn't mean "in the code abstract it" it means "in the project, abstract it"
20:18:51 <shardy> zaneb: I agree, low priority, but if someone wants to contribute the patch, fine
20:18:52 <sdake> i just added it because we had a discussion on irc about it
20:19:09 <zaneb> sdake: it isn't on *my* list ;)
20:19:16 <SpamapS> zaneb: its on mine
20:19:30 <SpamapS> and by "it" I mean making clear the line between AWS and Heat
20:19:31 <sdake> one of the resource types was on mine as well
20:20:04 <SpamapS> the "how" of that is not all that important to me.
20:20:23 <SpamapS> but I appreciate you guys setting me on a path toward filter vs. reorg code base. :)
20:20:34 <sdake> here is another way to frame the question - what is the harm of putting the aws stuff in one dir and the os stuff in another dir
20:21:05 <SpamapS> sdake: no harm, but what is the benefit? My "it helps you turn AWS off" argument doesn't really work :p
20:21:08 <shardy> sdake: I guess the question is more, is it worth the effort involved
20:21:21 <asalkeld> shardy, +1
20:21:25 <sdake> it helps devs understand what is what - readability issue
20:21:28 <stevebaker_> it makes it obvious where to find the code for a resource type
20:21:31 <asalkeld> also code churn
20:21:31 <sdake> otherwise the code is spread all over the place
20:21:40 <stevebaker_> which currently it is not (obvious)
20:21:59 <zaneb> sdake: <zaneb> I'm not against better code organisation
20:22:02 <zaneb> SpamapS: +1
20:22:48 <shardy> sdake: Ok, cool, seems like nobody's against the reorg, just nobody's particulary keen to do it themselves ;)
20:22:48 <sdake> in my mind its not about turning aws off and on, its about helping developers come up to speed on the code base and add more native resource types
20:23:11 <SpamapS> makes sense
20:23:13 <alexheneveld> sdake: that's worth a lot
20:23:50 <stevebaker_> maybe this is something we do immediately after havana-1 (or another release)
20:23:54 <sdake> i think spamaps _was_ keen :)
20:24:01 <sdake> stevebaker_ +1
20:24:08 <stevebaker_> to reduce the disruption from code churn
20:24:12 <SpamapS> Might still get motivated.
20:24:45 <shardy> Ok, agree lets leave this until after h-1 and see if anyone wants to post a patch
20:25:02 <shardy> can be under abstract-aws BP since we have separate BPs for each native resource?
20:25:04 <sdake> shardy when is h1?  3 weeks?
20:25:09 <shardy> two weeks
20:25:15 <zaneb> s/a patch/a lot of small patches/ please
20:25:43 <jpeeler> May 30 - havana-1
20:25:44 <shardy> So if anyone has anything they thing is/isn't going to land, please move the milestone target in LP :)
20:26:25 <shardy> in particular jpeeler and stevebaker_ you have a lot of bugs so please bump those you think will slip
20:26:38 * shardy should've created an agenda item for this..oops
20:26:40 <stevebaker_> I'll look
20:26:52 <shardy> Anyway, shall we move on?
20:26:53 <jpeeler> shardy: is there a particular commit date so to speak?
20:27:38 <shardy> jpeeler: well bear in mind reviews have been slow lately so I'd say anything not posted by the end of next week will probably slip, but we'll see how it goes I guess
20:29:08 <shardy> #topic heat-templates target audience
20:29:35 <shardy> So this was prompted by a discussion with pfreund in #heat
20:29:38 <pfreund> yes
20:30:17 <shardy> wanted to get peoples ideas about the targe audience of heat-templates, ie should it be purely for heat examples, or should there be a (probably unsupported) "contrib" area or something
20:30:30 <SpamapS> been meaning to reply to the thread...
20:30:35 <pfreund> I wrote an e-mail in openstack-dev list
20:30:37 <shardy> ie to try to get a community of testers and template authors interested in heat
20:30:53 <SpamapS> I think we should make it really obvious that the heat-templates repo exists..
20:30:59 <SpamapS> and tell all users about it..
20:31:09 <SpamapS> but stay out of defining policy for it just yet
20:31:09 <shardy> One concern I have is the idea that we provide supported "production ready" templates, which I think we should not
20:31:31 <shardy> but encouraging reuse and collaboration has to be good right?
20:31:33 <stevebaker_> My thoughts on this is that each top-level directory of heat-templates should have a readme describing what the target audience for those templates should be. for cfn/ the audience is something like "people exploring heat's capabilities"
20:31:34 <therve> shardy, Why not?
20:31:35 <shardy> any thoughts?
20:31:37 <SpamapS> shardy: right, I think we'll get to a place where having a collection of those is a good thing, but we shouldn't do it yet.
20:31:58 <shardy> therve: because it would involve effort that we as a team cannot currently afford
20:32:05 <jpeeler> production templates could have security implication responsibilites we don't want
20:32:11 <SpamapS> You need a whole community of motivated users to make such a collection work.
20:32:23 <shardy> jpeeler: agreed
20:32:32 <randallburt> shardy: I disagree a bit in that I don't think its unreasonable to expect that the templates we use for validating heat will deploy on a stock install of the service
20:32:34 <therve> shardy, OK, it's not a disagreement, just a resource issue
20:32:58 <shardy> SpamapS: yep, I guess the question I'm asking is is heat-templates the place for that collection?
20:33:21 <shardy> randallburt: the "test/demo/validation" templates would absolutely be expected to work
20:33:26 <asalkeld> yea, so don't  discourage production templates, just have a way of saying if each template is example/poc/whatever
20:33:45 <stevebaker_> if someone turns up with a production template and wants to maintain it in heat-templates I think we should let them
20:33:46 <shardy> this is about, should we allow loads of user templates, ie too many to reasonably test and maintain
20:33:50 <randallburt> asalkeld exactly
20:33:53 <SpamapS> shardy: probably not. To be really scalable the collection needs to be more distributed than a single git repo can do.
20:33:54 <alexheneveld> #idea let these live in people's githubs.  we keep a wiki page linking to them.
20:34:07 <shardy> And also should we talke responsibility for something people will use in production
20:34:13 <zaneb> therve: it's a question of, "do we want to be responsible for supporting this?"
20:34:20 <therve> zaneb, I see.
20:34:26 <therve> I guess we can wait for the problem to come up :)
20:34:27 <zaneb> therve: and the answer is "oh, G*d no"
20:34:41 <pfreund> When I said production ready, it was more meaning "templates who can be copied for real production template", still has an example, but not only a functionnality per template
20:34:49 <shardy> zaneb: lol, exaaactly ;D
20:34:50 <pfreund> still as
20:34:51 <SpamapS> Users who want to reduce duplication of effort as Heat gains adoption will probably want to be responsible for it.
20:35:04 <m4dcoder> i think heat-templates should be for development/validation purposes of hea.  there should be a separate public template catalog for the communities to contribute their templates.
20:35:11 <stevebaker_> zaneb: but hosting somebody's templates doesn't necessarily imply that we're supporting them
20:35:16 <therve> zaneb, Sure, but if someone comes tomorrow and say "Here's a great template to deploy X", there is no reason to refuse it.
20:35:26 <zaneb> right, and that's totally cool
20:35:42 <alexheneveld> therve: and we should point to it but not own/maintain it
20:35:48 <pfreund> stevebaker_, +1
20:35:48 <asalkeld> one reason not to do it, is the review burden
20:35:57 <therve> There is no warranty of any kind for sure
20:35:57 <randallburt> therve: as long as they also say "and I'll fix the bugs reported against it…"
20:36:11 <shardy> stevebaker_, therve: right, provided we have a way of distinguishing supported from unsupported (or at least "less supported"
20:36:22 <therve> asalkeld, I think it's a good problem to have :)
20:36:31 <shardy> asalkeld: that is true, we've been struggling with that lately
20:36:41 <stevebaker_> shardy: that could be stated explicitly in the readme
20:37:36 <jpeeler> we'd need to make it clear in each template explicitly as well i think
20:37:51 <zaneb> we could require people to put the name of the author in the template
20:37:52 <shardy> Ok, well there's a thread on openstack-dev "Introducing heat-templates", feel free to weigh in there
20:38:01 <stevebaker_> just as well yaml supports comments :)
20:38:25 <zaneb> stevebaker_: yah, I can't actually believe aws used a format without them
20:38:35 <alexheneveld> stevebaker_: absolutely single biggest advantage over json
20:38:51 <sdake_> who needs comments anyways ;)
20:39:01 <shardy> Should we move on and let the discussion continue on the ML?
20:39:20 <alexheneveld> re catalog -- the way jekyll (markdown) does it is nice -- wiki-style list people can update at the bottom of http://jekyllrb.com/docs/plugins/ -- quality and discussion is at the bottom
20:39:44 <shardy> #topic Open discussion
20:39:55 <stevebaker_> shardy: oi, one more item
20:40:07 <shardy> stevebaker_: there is?
20:40:13 * shardy refreshes his browser
20:40:18 <shardy> #undo
20:40:19 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x26f8a10>
20:40:46 <shardy> #topic Linking to downloadable tripleo built images
20:41:12 <stevebaker_> so tripleo are autobuilding some heat-cfntools enabled images
20:41:17 <stevebaker_> http://jenkins.tripleo.org:8080/job/autobuilt-images/elements=ubuntu%20vm%20heat-cfntools/
20:41:26 <stevebaker_> http://jenkins.tripleo.org:8080/job/autobuilt-images/elements=fedora%20vm%20heat-cfntools/
20:41:33 <stevebaker_> which I've been using for my tempest development
20:41:33 <SpamapS> Yes plesae try them! :)
20:41:43 <shardy> #link http://jenkins.tripleo.org:8080/job/autobuilt-images/elements=fedora%20vm%20heat-cfntools
20:42:07 <asalkeld> might need a version number in the link
20:42:07 <stevebaker_> ubuntu one is pretty good, fedora one has a bunch of pending reviews and might need a bit for fixing
20:42:25 <SpamapS> asalkeld: ?
20:42:28 <asalkeld> elements=fedora18x86_64
20:42:37 <asalkeld> not just fedora
20:42:45 <stevebaker_> but when fedora is ready I'd like to propose that switch all links to prebuilt images to these ones
20:42:57 <SpamapS> asalkeld: we use the latest always :)
20:42:59 <asalkeld> +1 on the idea
20:43:02 <hanney> +1
20:43:03 <shardy> stevebaker_: Who will maintain them?
20:43:05 <SpamapS> about to switch ubuntu to 13.04
20:43:09 <shardy> +1 too btw ;)
20:43:33 <SpamapS> but would be more than happy to accept changes to have multiple versions if thats what is needed
20:43:37 <stevebaker_> shardy: jenkins will ;)
20:43:52 <shardy> anything that gets us away from having to maintain an image repo gets my +100 provided the alternative images work
20:43:58 <zaneb> stevebaker_: that is the correct answer :)
20:44:01 <stevebaker_> seriously, if they're part of tempest gating we will all be maintaining them on every commit
20:44:09 <stevebaker_> ...however
20:44:21 <SpamapS> Those images are built from  github.com/stackforge/diskimage-builder and github.com/stackforge/tripleo-image-elements
20:44:29 <shardy> stevebaker_: I mean who will own the template definitions etc, where are they, gotta link?
20:44:44 <shardy> SpamapS: pre-empted my question :D
20:44:49 <stevebaker_> today I got this comment on a review https://review.openstack.org/#/c/28650/
20:45:03 <stevebaker_> shardy: tripleo-image-elements heat-cfntools is our element
20:45:43 <stevebaker_> so eventually this image building will result in some blessed images being hosted from stack.openstack.org
20:46:24 <shardy> stevebaker_: Ok, sounds good :)
20:46:35 <SpamapS> Right, these images will be used not only in gating tempest/heat, but hopefully in the tripleo gate for all of openstack.. eventually
20:46:41 * shardy will not miss watching oz fail after running for 10mins
20:46:43 <stevebaker_> until that happens I am suggesting:
20:46:45 <stevebaker_> 1. link to jenkins.tripleo.org as soon as the fedora image is good enough (and delete our old prebuilt images)
20:46:47 <stevebaker_> 2. link to stack.openstack.org when that happens
20:47:43 <shardy> Can we maintain multiple fedora versions? That link doesn't specify what Fedora version?
20:48:08 <shardy> ie atm F17 works with heat but F18 doesn't (unless you use updates-testing cloud-init which I pushed)
20:48:21 <sdake_> how about epel and scientific linux as well?
20:48:33 <SpamapS> Its F18
20:48:39 <shardy> so I think maintaining images for all non-eol versions of platforms we care about would be good
20:48:44 <stevebaker_> I think tripleo are receptive to building different images, but I don't know what the upper limit is ;)
20:48:46 <SpamapS> "patches accepted"
20:48:48 <shardy> s/we/we or our users/
20:49:12 <SpamapS> DIB_CLOUD_IMAGES=${DIB_CLOUD_IMAGES:-http://mattdm.fedorapeople.org/cloud-images/}
20:49:15 <SpamapS> DIB_RELEASE=${DIB_RELEASE:-Fedora18}
20:49:16 <shardy> SpamapS: as mentioned above, F18 is broken until my cloud-init update gets promoted from updates-testing
20:49:48 <SpamapS> those both can be overriden so.. bring it on. :)
20:49:58 <stevebaker_> shardy: maybe a fedora-updates-testing dib element is needed
20:50:02 <shardy> so we need a F17 version as well, and every release, there's always overlap while we work through the latest round of upgrade-brokenness
20:50:27 <SpamapS> unfortunately, mattdm does not make F17 images
20:50:31 <SpamapS> so...
20:50:33 <stevebaker_> and i386 and x64 versions of each...
20:50:43 <shardy> stevebaker_: I think we need images available for all non-eol versions, but an updates-testing image could also be good I guess
20:50:54 * shardy is a bit scared of updates-testing in general
20:51:03 <SpamapS> don't be scared its just crack
20:51:09 <sdake_> dont run updates testing in images
20:51:12 <sdake_> it breaks things badly
20:51:13 <stevebaker_> SpamapS: fyi fedora 19 will have an official openstack image download
20:51:18 <sdake_> trust me been there done that
20:51:20 <SpamapS> stevebaker_: \o/
20:51:58 <shardy> stevebaker_: link? and will it have heat-cfntools?
20:52:01 <SpamapS> Ok well please do discuss needs in #tripleo and we have a bug tracker too launchpad.net/diskimage-builder
20:52:31 <SpamapS> I had one other topic that I wanted to bring up
20:52:31 <shardy> SpamapS: OK, other than the single-fedora-version this all sounds good
20:52:49 <m4dcoder> shardy: regarding bp on UpdateStake support for ScalingPolicy, what's the expected behavior?  Any example?  Is it just handling the update of a ScalingPolicy resource?  I see there's update for cloud watch alarm and ASG already.
20:52:50 <shardy> anyone got anything else, 8mins left
20:52:51 <stevebaker_> https://github.com/stackforge/tripleo-image-elements
20:52:53 <stevebaker_> https://github.com/stackforge/diskimage-builder
20:52:58 <SpamapS> Namely that Heat needs to be more responsive to the OpenStack underneath it.
20:53:14 <shardy> m4dcoder: shall we discuss that in #heat after the meeting?
20:53:19 <m4dcoder> ok
20:53:33 <SpamapS> I wanted to float the idea that "UpdateStack" would re-create any underlying resources that have gone missing
20:53:58 <shardy> SpamapS: out of interest, why would they go missing?
20:53:59 <SpamapS> meaning, if I nova delete an instance, and then UpdateStack comes along and sees that instance id is gone.. it will create a new instance.
20:54:08 <SpamapS> shardy: out of band reasons
20:54:27 <shardy> out-of-control admins ;)
20:54:39 <therve> I'm not sure UpdateStack is the proper place for this
20:54:44 <SpamapS> So for instance lets say during the initial bring up the instance was stuck
20:54:55 <therve> It seems it would be desirable to maintain the state all the time.
20:55:01 <SpamapS> bad mirror, or bad compute host.. basically "s*** happens"
20:55:26 <shardy> therve: I agree, we can't be expected to recover from all insane out-of-band hackery which may happen
20:55:32 <SpamapS> actually
20:55:34 <SpamapS> yes we can
20:55:38 <shardy> hmmm
20:56:05 <SpamapS> I don't see why Heat should be completely rigid
20:56:19 <therve> shardy, Well I'm saying we should restart the instance. Just not in UpdateStack
20:56:27 <shardy> SpamapS: sounds worthy of discussion anyway - care to raise a BP?  I know we have a bug about restarting a failed update, but this is something different
20:56:31 <SpamapS> shardy: the alternative is I have to rename the resource, so that heat will re-create it.
20:56:34 <stevebaker_> related to this, I've been thinking about a stack abandon/adopt
20:56:41 <shardy> therve: we already can via the IHA mechanism
20:56:50 <stevebaker_> abandon is like a stack delete which doesn't delete the resources
20:56:52 <SpamapS> shardy: its all going to the problem of resiliency to external factors, and yes I think a BP is in order. :-P
20:57:10 * therve looks it up
20:57:18 <SpamapS> stevebaker_: yeah I like that idea, that would also work
20:57:23 <zaneb> stevebaker_: you can already set a DeletionPolicy on resources
20:57:26 <stevebaker_> adopt will recreate a stack based on existing (possibly abandoned) resources
20:57:27 <SpamapS> ok I'll write up a formal proposal
20:57:45 <SpamapS> have already started working on some poc patches
20:57:48 <shardy> SpamapS: I'm in favor of resiliency, I just think it should be something you explicitly enable rather than a behind-the-scenes feature of UpdateStack, cos it's actually a recovery action
20:57:48 <alexheneveld> SpamapS: UpdateStack = neat idea -- would having a way to write idempotent templates achieve the same end ?
20:58:35 <shardy> SpamapS: IMO it actually fits a heat stack create retry pattern better, where you can re-create a stack based on the current definition
20:58:47 <SpamapS> alexheneveld: thats just the thing.. I think the current templates should be idempotent. :)
20:59:03 <shardy> but we're nearly out of time, so can followup elsewhere..
20:59:05 <SpamapS> agreed
20:59:07 <alexheneveld> well sometimes i want 2 wordpresses :)
20:59:12 <shardy> #endmeeting