20:00:29 <shardy> #startmeeting heat
20:00:30 <openstack> Meeting started Wed May  8 20:00:29 2013 UTC.  The chair is shardy. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:34 <openstack> The meeting name has been set to 'heat'
20:00:42 <shardy> #topic rollcall
20:00:45 <SpamapS> o/
20:00:48 <therve> Hola
20:00:50 <mrutkows> here
20:00:56 <jpeeler> hi
20:01:01 <randallburt> hi folks
20:01:03 <adrian_otto> hi
20:01:04 <kebray> Hello
20:01:26 <hanney> o/
20:01:40 <wirehead_> heya
20:02:12 <stevebaker> o/ (i'll have to leave early)
20:02:17 <asalkeld> o/
20:02:27 <harlowja> yo
20:02:36 <shardy> Ok, cool, zaneb said he can't attend today also
20:02:53 <shardy> Well hi all, let's get started :)
20:03:04 <shardy> #topic Review last week's actions
20:03:20 <shardy> all to take a look at harlowja's wiki page and patch
20:03:36 * oubiwann high-fives therve
20:03:42 <shardy> I had a look at the wiki page, but forgot to look at the patch, sorry harlowja
20:03:50 <harlowja> its fine, the patch is 'evolving'
20:04:09 <adrian_otto> there are multiple wiki pages. Can you specify which you are referring to? Please offer a link.
20:04:35 <shardy> adrian_otto: they are linked in the last weeks minutes, but here:
20:04:45 <shardy> #link https://wiki.openstack.org/wiki/NovaOrchestration/WorkflowEngines
20:04:54 <harlowja> *thats an old one :)
20:04:55 <shardy> #link https://wiki.openstack.org/wiki/StructuredStateManagement
20:05:17 <shardy> #link http://eavesdrop.openstack.org/meetings/heat/2013/heat.2013-05-01-20.00.html
20:05:17 <adrian_otto> thanks, I'm familiar with that one
20:05:28 <kebray> familiar here as well.
20:05:33 <harlowja> there are some ideas being thrown around as to placement of said library, still in progress i think
20:05:44 <harlowja> *its a little bit of an odd duckling
20:05:54 <shardy> The main question I have - is the plan still to create a small library, then build on it?
20:06:10 <shardy> I didn't like the look of the long list of existing WorkflowEngines much
20:06:31 <harlowja> shardy so yes i think the small library approach is still the ideal
20:06:31 <adrian_otto> yes, we want to create a StackForge project, make a small library, then iterate on it
20:06:40 <shardy> Ok, sounds good
20:06:50 <adrian_otto> when it makes sense to start pulling in patches to add features or solve issues in Heat, we can pull those over
20:06:59 <shardy> Anyone else got anything on this or should we move on?
20:07:10 <sdake> o/
20:07:14 <shardy> hey sdake
20:07:18 <sdake> sorry late - late lunch
20:07:18 <adrian_otto> we are working to have representatives from multiple OpenStack projects on the TaskFlow Stackforge project in order to boost alignment
20:07:41 <adrian_otto> that should make integration later easier, as there should be less to debate
20:07:46 <harlowja> yup
20:07:47 <kebray> We have confirmed representation on the STackForge TaskFlow project for Reddwarf.
20:08:17 <harlowja> and i am sorta connected with nova, but i am not a core represenative
20:08:22 <shardy> adrian_otto: sounds good, definitely sounds like we'll have someone involved also
20:08:50 <adrian_otto> ideally a core member from each interested project
20:09:09 <harlowja> yes, that would be nice
20:09:12 <adrian_otto> but what I am concerned with mostly today is taht we don't stagger innovation and progress by having too much red tape
20:09:13 <shardy> Unless anyone wants to volunteer now, perhaps we can discuss and come back to you with who (as zaneb is not here and I know he's possibly interested in this area)
20:09:21 <harlowja> adrian_otto 100% agree
20:09:28 <adrian_otto> let's get everyone thinking, organized and coding together.
20:09:37 <harlowja> :)
20:09:41 <shardy> adrian_otto: +1
20:10:26 <shardy> Ok couple more actions to check:
20:10:40 <shardy> randallburt assign names to new BPs linked above
20:10:49 <shardy> randallburt: this is done now right?
20:10:51 <randallburt> asalkeld got the assignments sorted so we should be good.
20:10:58 <shardy> Ok, great
20:11:07 <shardy> zaneb to add details to Provider BPs
20:11:16 <shardy> I'm pretty sure zaneb did this
20:11:26 <shardy> everyone to target bp's likely to land in next 2-3 weeks to havana-1
20:11:30 <randallburt> He did for the couple I looked at
20:11:53 <shardy> So this looks good, if anyone has anything they expect to land for h-1 please make sure it's targetted in LP
20:12:05 <shardy> SpamapS to raise BP re available resources
20:12:16 <shardy> SpamapS: Pretty sure you did this?
20:12:33 <SpamapS> I did
20:12:56 <shardy> Ok, thanks
20:12:58 <SpamapS> https://blueprints.launchpad.net/heat/+spec/discover-catalog-resources
20:13:14 <shardy> #link https://blueprints.launchpad.net/heat/+spec/discover-catalog-resources
20:13:39 * shardy should've been using info for all those action bullets, oops
20:14:05 <shardy> So I only added one topic, which is:
20:14:16 <shardy> #topic Stable Branch policy cont'd
20:14:49 <shardy> We kinda discussed this last week, but I wanted to proposed that we align with what Ceilometer are doing:
20:15:07 <shardy> - Support Folsom as a best-effort via stable/grizzly
20:15:28 <shardy> - stop worrying too much about backwards compatibility in master
20:15:55 <shardy> - Align with the openstack stable-branch policy for all backports
20:16:06 <shardy> #link https://wiki.openstack.org/wiki/StableBranch
20:16:29 <therve> It sounds fine to me
20:16:31 <shardy> Does this sound reasonable to everyone?
20:16:51 <asalkeld> yea
20:17:03 <sdake> will there be forward compatibility?
20:17:07 <SpamapS> +1 for not worrying about BC w/ Folsom in master
20:17:14 <stevebaker> There are quite a few users interested in using latest heat will folsom/grizzly openstacks
20:17:22 <shardy> sdake: forward compatibility?
20:17:32 <sdake> ie grizzly->havana
20:17:32 <shardy> you mean the templates?
20:17:49 <shardy> upgrade path, db migrations etc?
20:17:51 <sdake> an upgrade path
20:17:53 <sdake> yup
20:18:00 <shardy> Yes, definitely
20:18:04 <stevebaker> I'd like users who want to use latest heat against folsom/grizzly to self-organise and do the regression testing themselves, and feed us fixes
20:18:22 <randallburt> stevebaker:  +1
20:18:24 <asalkeld> the move to ceilometer for alarms is going to be messy
20:18:28 <stevebaker> so we don't have to worry about BC w/ Folsom in master but we are receptive to those who are
20:18:28 <SpamapS> We should not break network API compatibility.. but I stand by my charge that the software dependencies present/not-present are orthogonal to that
20:18:36 <asalkeld> if people are using alarms
20:19:01 <shardy> stevebaker: agree, but there's some stuff, e.g trusts which only exist in >= grizzly, and as asalkeld say all the new CM alarm stuff
20:19:10 <stevebaker> hmm alarms
20:19:32 <asalkeld> (as the alarm table in heat will need to be ditched and recreated in ceilometer)
20:19:33 <SpamapS> asalkeld: indeed, Havana should maintain "the old way" for alarms, but deprecate it. So that there is a phased migration path.
20:19:35 <shardy> I think we've reached (or soon will be reaching the point where it's hard to keep master working on Folsom, and perhaps soon grizzly)
20:20:06 <SpamapS> also, IMO we need to get stuff like this in the gate
20:20:10 <shardy> Yep, make the new alarms code default, but have config option for the old stuff, say for one more cycle
20:20:43 <asalkeld> not so easy
20:21:10 <stevebaker> its up to these users to explicitly tell us what is important to them. I'm going to send an email to kick the process off
20:21:11 <SpamapS> asalkeld: not easy, but critical to holding on to early adopters
20:21:22 <shardy> asalkeld: alarms will be a one-way change?
20:21:29 <asalkeld> yea
20:21:32 <shardy> SpamapS: exactly
20:21:49 <therve> We would need some kind of functional testing to be able to maintain that properly
20:21:57 <SpamapS> If somebody has deployed grizzly heat, we should pretty much buy them tiaras and scepters and carry them around on a liter with a throne on top of it at the next summit.
20:22:29 <stevebaker> I was thinking the new tempest tests could be also run against old openstacks, but that is handled by the people wanting that use case
20:22:37 <therve> stevebaker, +1
20:22:39 <SpamapS> oh, and we should probably try to test their migration too. :)
20:22:53 <oubiwann> SpamapS: man, you make a good princess pitch
20:22:59 <asalkeld> I suspect xlcloud is someone we should talk to about it
20:23:04 <oubiwann> I've got a couple takers here in the office
20:23:18 <SpamapS> stevebaker: Yeah, lets get the tempest against current openstack first.. but an immediate goal thereafter should be to run it against havana heat + grizzly.
20:24:04 <stevebaker> SpamapS: yep, but I wouldn't count on the CI infrastructure doing that for us
20:24:20 <SpamapS> stevebaker: I would... but.. my boss runs it and he loves stuff like that. :)
20:24:27 <SpamapS> mordred: ^^
20:25:04 <shardy> Ok, so master should ideally work with havana/devstack and stable/grizzly, but there may be documented workarounds to run on grizzly (e.g bleeding edge client libraries which we're already starting to need)
20:25:10 * mordred reads scrollback
20:25:41 <adrian_otto> mordred: welcome
20:25:48 <mordred> we would LOVE to do cross-version testing of stuff - but we still don't have that with novaclient+nova yet
20:25:58 <mordred> so - you know - it might not happen quickly :)
20:26:08 <clarkb> stevebaker: fwiw I think we probably can run it, just that it probably wouldn't happen as part of the larger integration gate
20:26:09 <stevebaker> imagine the cross-version permutations, ouch
20:26:34 <shardy> stevebaker: I think if we're not careful it could be come a huge resource-sink
20:26:51 <shardy> Be better to say "n-1 version is untested and best-effort"
20:27:40 <shardy> ie if problems are reported we'll try to fix, and try to avoid knowingly merging stuff which will obviously break with grizzly?
20:28:07 <shardy> maybe we need a vote, but I'm not sure exactly what we're voting on ;)
20:28:10 <stevebaker> yep, but my point is it is less of a resource sink if we're not doing the work, the people who are interested in this are
20:28:28 <shardy> stevebaker: completely agree
20:28:37 <stevebaker> nothing yet, action point for me to email who is interested
20:28:44 <SpamapS> Ok, so we need to vote only on policy.
20:29:01 <SpamapS> Basically, will we respond to bug reports about X with yay or nay.
20:29:05 <shardy> #action stevebaker to send ML email re backwards-compatibility
20:29:19 <SpamapS> X being. "trunk running against grizzly" or "stable running against folsom"
20:29:55 <stevebaker> SpamapS: bug reports on old openstack versions without provided fixes may be politely declined ;)
20:30:16 <mrutkows> Really hate to leave early for the first Heat meeting, but have a conflict the 2nd half of this hour... hope to be more of a regular from now on
20:30:29 <therve> shardy, it seems reasonable to include backward compatibility concerns in the review process. Without automation it's wishful thinking though
20:30:31 <shardy> mrutkows: np o/
20:31:11 <stevebaker> therve: yep
20:31:28 <shardy> therve: well until now we have done it manually, but yes agree automation would be great if someone's willing to do it for us ;)
20:31:40 <stevebaker> should we move on?
20:31:43 <shardy> yep
20:31:59 <shardy> we can follow up on the ML thread started by stevebaker
20:32:13 <shardy> #topic Open discussion
20:32:38 <shardy> Anyone have anything to discuss?
20:32:54 <SpamapS> heat-cfntools ...
20:33:05 <tspatzier> I have some news on the open-api-dsl topic ..
20:33:14 <SpamapS> oo lets do tspatzier's first
20:33:31 <shardy> tspatzier: go for it :)
20:34:03 <shardy> tspatzier: I saw your heat-templates review, not finished going through all three templates yet
20:34:04 <tspatzier> So, I've posted a patch for review about an hour ago to add some variants of the WordPress_Single_Instance template to the heat-templates repo
20:34:13 <tspatzier> #link https://review.openstack.org/28598
20:34:31 <tspatzier> Would be interested in everyone's feedback
20:35:09 <shardy> tspatzier: great, thanks for this
20:35:13 <tspatzier> SpamapS: based on that, I also plan to sketch something in reply to the recent ML discussion ...
20:35:27 <shardy> #action all to look at dsl examples and provide feedback
20:36:14 <shardy> Any more to add on this, or should we go to SpamapS topic?
20:36:24 <tspatzier> Let's move on
20:36:45 <SpamapS> So, heat-cfntools ..
20:36:59 <SpamapS> I've been doing some poking and prodding of it, and generally trying to get it in shape for my use case..
20:37:19 <SpamapS> But shardy pointed out that this is all very cfn centric, so time spent on it is dead-tools time.
20:37:52 <SpamapS> I am wondering if the HOT template developers have given much thought to an in-instance agent, which is most of what makes heat-cfntools interesting to me (cfn-hup)
20:38:38 <asalkeld> no polling?
20:38:38 <tspatzier> SpamapS: We thought of something like generic "providers" that do in-instance software config
20:38:47 <SpamapS> not config
20:38:55 <SpamapS> cfn-init does that...
20:38:58 <SpamapS> and I don't like it at all
20:39:04 <tspatzier> Ah, I see
20:39:06 <SpamapS> cfn-hup is just a triggering mechanism
20:39:20 <SpamapS> it is meant to expose the timing of updates from the orchestration engine to the instance software
20:39:21 <asalkeld> we need a communication path
20:39:35 <stevebaker> SpamapS: have you thought of building what you need in (or on top of) python-heatclient?
20:39:46 <randallburt> SpamapS: not really. Had hoped to avoid it tbh.
20:39:48 <SpamapS> stevebaker: no, but that makes perfect sense.
20:39:55 <shardy> basically we'll need heat-ostools to provide all of our current functionality without the cfn-compatible API
20:39:57 <SpamapS> randallburt: it cannot be avoided.
20:40:04 <SpamapS> otherwise you're not doing real orchestration
20:40:09 <shardy> (which is not necesarily related to the template format)
20:40:10 <randallburt> SpamapS: yeah, but I had *hope*
20:40:15 <randallburt> ;)
20:40:22 <stevebaker> SpamapS: do you need anything other than cfn-hup(ish)
20:40:23 * SpamapS lights randallburt's hope on fire
20:40:50 <wirehead_> ugh
20:41:15 <shardy> I think all we actually need is cloud-init and a metadata-monitor tool (cfn-hup-ish) which talks to the ReST API
20:41:16 <SpamapS> stevebaker: not really, i just need "cache metadata locally, run hooks on update"
20:41:20 <therve> SpamapS, what are your requirements, regardless of cfn-hup?
20:41:37 <SpamapS> shardy: cloud-init is completely orthogonal to this.
20:41:37 <shardy> We don't need cfn-init for HOT templates IMO, it's a CFN compatibility thing
20:41:39 <SpamapS> completely.
20:41:53 <shardy> SpamapS: someone mentioned cfn-init
20:42:04 <SpamapS> unless you re-work cloud-config to be its own tool, which is I suppose doable.
20:42:07 <sdake> if idea is to drop cfn, wont that break forward compatibility?
20:42:09 * randallburt rekindles hope!
20:42:21 <asalkeld> sdake, not drop
20:42:24 <shardy> sdake: not drop, make optional
20:42:32 <asalkeld> just add a new better tool
20:42:35 <sdake> i see
20:42:46 <SpamapS> ok anyway, lets not design it here, but I wanted to see if anybody else was thinking on this subject
20:42:50 <asalkeld> better response to updates
20:43:13 <adrian_otto> I'll add support to SpamapS to do away with config in the new DSL
20:43:17 <SpamapS> My thinking is if we can tap into the unified notifications bits that have been talked about on openstack-dev, we can use that.
20:43:51 <asalkeld> SpamapS, +1 to a standalone tool that can respond to heat-engine quickly
20:43:52 <tspatzier> adrian_otto: +1, we should do this
20:44:00 <shardy> adrian_otto: it's not just config though, its triggering in-instance actions in response to stack updates
20:44:12 <SpamapS> So, as HOT is fleshed out, lets make sure we think about these tools as they will be important.
20:44:35 <tspatzier> Are there concrete use cases documented somewhere?
20:44:38 <adrian_otto> I am looking at the https://review.openstack.org/#/c/28598/1/hot/WordPress_Single_Instance-alt1.yaml and I think we missed the mark a little
20:45:04 <adrian_otto> the idea is not to reconstruct the mappings in the DSL with options and inputs
20:45:07 <shardy> SpamapS: want to take an action to start a ML discssion on this topic?
20:45:09 * stevebaker has to leave; later
20:45:17 <shardy> stevebaker: o/
20:45:49 <SpamapS> tspatzier: when you replace your memcache server with a bigger server, the Metadata for your instances will all be changed. You want to re-apply config files to point at the new servers, re-start your app servers, and run cfn-signal to tell Heat you've completed that so its ok to move forward with orchestrating things dependent on that action.
20:46:12 <SpamapS> shardy: I don't actually.. I think its premature.
20:46:15 <shardy> cfn-signal is just curl
20:46:23 <SpamapS> shardy: I will add some notes to the HOT wiki page.
20:46:41 <sdake> definitely need wait conditions
20:46:52 <shardy> SpamapS: Ok, as long as we start capturing some of the actual requirements somewhere
20:46:57 <tspatzier> adrian_otto: sure, let's iterate on it. I laid much focus on cfn compatibility to keep supporting the content, but it's only a first shot
20:47:05 <adrian_otto> ok
20:47:10 <adrian_otto> thanks for putting those up
20:47:13 <SpamapS> shardy: right, thats what I'm going to add. I just think talking about the tools will get in the way of the HOT discussion.
20:47:19 <adrian_otto> we can polish them a bit more
20:47:47 * asalkeld is not a fan of the mapping section
20:47:53 <shardy> SpamapS: Ok, well good to get the discussion started
20:48:45 <SpamapS> adrian_otto: thats a nice direct translation, if we can make that work, we have something. Agreed that it has too many details about the systems to be the end goal.
20:49:11 <adrian_otto> SpamapS: YEP
20:49:58 <shardy> Any other topics to discuss?
20:50:06 <tspatzier> SpamapS: nice use case. We handle this with actions attached to links in TOSCA (think of it as something like 'target-added', 'target-removed', 'target-changed' ...)
20:50:21 <SpamapS> Only that you are all amazing and its realy exciting to see all this steam build up behind Heat. :)
20:50:38 <randallburt> badumpump
20:50:51 <SpamapS> :)
20:50:53 * adrian_otto hits the hihiat
20:51:03 <shardy> haha
20:51:09 * kebray wants to play cow bell.
20:51:13 <shardy> Yep, great job everyone :)
20:51:33 <shardy> If there's nothing else we can finish early?
20:51:42 <wirehead_> well, given that this is heat, the calliope is our official musical instrument
20:51:59 * shardy has to google calliope
20:52:10 <wirehead_> steam powered musical instrument
20:52:21 <SpamapS> shardy: yes please make it stop
20:52:28 <shardy> #endmeeting