20:00:53 <shardy> #startmeeting heat
20:00:54 <openstack> Meeting started Wed May 29 20:00:53 2013 UTC.  The chair is shardy. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:58 <openstack> The meeting name has been set to 'heat'
20:01:00 <hanney> o/
20:01:10 <zaneb> howdy y'all
20:01:14 <adrian_otto> hi
20:01:16 <jpeeler> here
20:01:21 <stevebaker> meep
20:01:23 <SpamapS> o/
20:01:24 <therve> Hi!
20:01:57 <shardy> asalkeld around?
20:02:00 <sdake_> o/
20:02:03 <asalkeld> hi
20:02:04 <radix> hello :)
20:02:19 <m4dcoder> O/
20:02:42 <shardy> hi all :)
20:02:48 <shardy> #topic Review last week's actions
20:03:09 <wirehead_> Heya
20:03:11 <kebray> hello
20:03:13 <TravT> hello!
20:03:21 <shardy> #info shardy PoC HOT patch
20:03:41 <shardy> so I did this, but I'm now preferring zaneb's followup patch
20:03:51 <sdake_> i prefer zanes as well
20:03:58 <shardy> #link https://review.openstack.org/#/c/30405/
20:04:18 <shardy> #link https://review.openstack.org/#/c/30439/
20:04:25 <zaneb> I added an item to the agenda to discuss this
20:04:30 <kebray> fyi, randallburt is out of office today, not feeling well.
20:04:37 <shardy> Ok, does anyone *not* think zaneb's approach is the way to go?
20:04:45 <therve> There seems to be a consensus on the new template class
20:04:56 <zaneb> I'd like to see some more input on my mailing list post
20:04:59 <shardy> I like it but it does mean we're committing to keeping the template translation in the engine
20:05:26 <asalkeld> shardy eventually we need to move cfn out
20:05:28 <fsargent> hiya
20:05:29 <stevebaker> zaneb: the one on file inclusion?
20:05:33 <asalkeld> so it is a start
20:05:35 <zaneb> stevebaker: yes
20:06:02 <zaneb> asalkeld: not sure I agree with your post
20:06:15 <shardy> asalkeld: yeah, or move the CFNisms into a CFNTemplate class
20:06:24 <stevebaker> zaneb: I prefer some kind of client-side file aggregation to zipping up template files
20:06:26 <zaneb> asalkeld: wouldn't it be better to have the engine mechanics independent of the template format?
20:06:30 <stevebaker> zaneb: tl:dr +1
20:06:43 <zaneb> asalkeld: rather than just tying it to HOT instead of CFN
20:06:51 <asalkeld> no
20:06:56 <zaneb> lol
20:07:21 <asalkeld> I think there is still heaps of time to sort it out
20:07:31 <asalkeld> get this patch in already
20:07:33 <shardy> zaneb: I really like the idea of decoupling the engine from template details, and just accessing Template class properties
20:07:53 <SpamapS> i thi k the template format is pretty closely tied to the engi e so this seems fi e
20:08:09 <zaneb> SpamapS: lost your 'n' key?
20:08:22 <sdake_> time for new keyboard imo ;)
20:08:22 <shardy> Ok, shall we continue discussions on the ML, and I'll abandon the template-mangle patch?
20:08:25 <asalkeld> I seriously doubt it is possible for details not leak out
20:08:27 <stevebaker> SpamapS: broken right thumb?
20:08:49 <asalkeld> (of the Template class)
20:08:54 <asalkeld> but we will see
20:09:08 <therve> Right that doesn't mean we shouldn't try though
20:09:12 <shardy> if people have specific issues, pls update https://review.openstack.org/#/c/30439/
20:09:37 <zaneb> asalkeld: you may be right. therve: I agree
20:09:47 <asalkeld> therve, totally think we need both format's in now
20:10:07 <asalkeld> just whether or not we kick cfn out
20:10:13 <asalkeld> (of the engine)
20:10:27 <therve> asalkeld, Agreed. We can improve things as they move on
20:10:31 <asalkeld> at some later point
20:10:39 <zaneb> asalkeld: vote it off the island :)
20:10:47 <therve> Right now it's a bit too abstract to figure out all the problems we'll encounter
20:10:48 <asalkeld> yea
20:10:51 <shardy> asalkeld: I guess we can decide that later :)
20:10:56 <asalkeld> for sure
20:11:07 <zaneb> fwiw...
20:11:46 <zaneb> I think moving from 2 Template classes in engine to cfn translation layer in API is easier than moving from HOT translation layer in API to cfn translation layer in API
20:12:02 <shardy> zaneb: agree
20:12:31 <shardy> Lets get the "superset model" in the engine, then work out where the template transformations live later
20:12:50 <therve> +1
20:12:55 <zaneb> +1
20:12:56 <kebray> +1
20:13:02 <shardy> #info action asalkeld wiki/bp re infra heat usage
20:13:05 <asalkeld> (I +2'd it)
20:13:16 <shardy> IIRC this happened, asalkeld got a link?
20:13:23 <asalkeld> mmm
20:13:36 <asalkeld> I can't even remember this
20:13:41 <asalkeld> wow getting old
20:14:00 <asalkeld> O, ok - hold on
20:14:03 <shardy> IIRC you did it immediately after the meeting
20:14:08 <asalkeld> (it is 6am)
20:14:10 <sdake_> use the wiki related links
20:14:33 <shardy> Ok, lets forget the link and move on :)
20:14:37 <SpamapS> this was clarkb wanting to use heat for logstash for infra stuff
20:14:38 <kebray> https://wiki.openstack.org/wiki/Heat/on-public-clouds
20:14:43 <kebray> That one?
20:15:05 <zaneb> I think it was another one
20:15:26 <asalkeld> that's it
20:15:39 <shardy> #topic h1 release status
20:15:51 <shardy> so h1 branched today, nice work everyone :)
20:16:09 <shardy> few things bumped to h2 but most of the stuff planned landed
20:16:24 <zaneb> I think we sort-of got parallel-launch in :)
20:16:30 <zaneb> except for nested templates
20:17:00 <shardy> zaneb: yeah, sorry we didn't manage to get the reviews in for the final few
20:17:07 <shardy> nice job anyways :)
20:17:13 <zaneb> np, was a pretty good effort
20:17:17 <zaneb> so many patches...
20:17:25 <therve> shardy, Any highlights on other things that got pushed?
20:17:31 * zaneb has fingers crossed for no more rebases
20:17:56 <shardy> therve: mainly a few quantum related bugfixes which are in-progress
20:17:58 <sdake_> zaneb rebases more fun then java fedora package reviews :)
20:18:12 <zaneb> sdake_: I'll drink to that
20:18:26 <shardy> going to be a busy h2 tho by the looks of it :)
20:18:34 <zaneb> shardy: 'milestone-proposed' is the branch, I assume?
20:18:53 <mrutkows> o/  sorry late
20:18:55 <shardy> #link https://launchpad.net/heat/+milestone/havana-2
20:19:18 <shardy> zaneb: yep, then we have couple of days (until tomorrow IIRC) where backported critical fixes can be proposed
20:19:32 <shardy> before the release is made final
20:19:49 <zaneb> weird system, but ok :)
20:19:52 <shardy> which takes us nicely on to:
20:20:01 <shardy> #topic 2013.1.2 stable release
20:20:20 <shardy> So I'm thinking we skip this as we don't have any backported fixes to grizzly/stable
20:20:40 <shardy> Does anyone have anything they want to flag as backport-potential?
20:20:51 <zaneb> +1 for skipping
20:21:06 <shardy> the main one is the latest-boto v4 signatures thing, but we need keystoneclient release before we can backport that
20:21:31 <shardy> (as SpamapS pointed out earlier)
20:22:09 <shardy> So if anyone wants to propose stable backports at any point, see this wiki:
20:22:16 <shardy> #link https://wiki.openstack.org/wiki/StableBranch
20:22:35 <shardy> #topic heat-core proposed changes
20:22:41 <shardy> So two things
20:23:06 <shardy> firstly, I'm proposing to remove shadower and Slower from heat-core as they're no longer actively contributing/reviewing
20:23:24 <shardy> here are the stats for the last 90 and 30 days:
20:23:28 <shardy> http://fpaste.org/15176/69819561/
20:23:38 <shardy> any objections?
20:23:55 <shardy> obviously we can add them again if they start working on Heat in the future
20:24:15 <stevebaker> +1
20:24:18 <sdake_> so just to clarify
20:24:23 <sdake_> and I agree they should be removed
20:24:27 <zaneb> interesting, SpamapS is the harshest reviewer :D
20:24:28 <sdake_> but what are your criteria for core
20:24:39 <SpamapS> i didnt even know who they were
20:24:39 <sdake_> zaneb: I'd thought you have been :)
20:24:52 <zaneb> close second ;)
20:24:59 <shardy> sdake_: so criteria is (IMHO):
20:25:00 <m4dcoder> What's the requirements to join core?
20:25:01 <sdake_> SpamapS they did some early work on heat
20:25:06 <stevebaker> core membership is for reviews more than anything else
20:25:25 <shardy> Active reviewer, with consistent and well thought out downvotes (not just +1 on everything)
20:25:57 <asalkeld> (but helps to code to know the code)
20:25:57 <shardy> Send some patches which prove you have some familiarity with the codebase and we can assess code-style/ability
20:26:19 <shardy> Be active in #heat, get to know us/discuss stuff
20:26:40 <shardy> attend these meetings from time to time and contribute to the discussions
20:26:53 <shardy> also ideally chime in on openstack-dev Heat related threads
20:26:57 <asalkeld> looks like therve is getting close
20:27:11 <shardy> asalkeld: that was going to be my second point! :)
20:27:20 <shardy> So I'd like to propose therve for heat-core
20:27:28 <asalkeld> oops, sorry to spoil
20:27:37 <asalkeld> +1
20:27:38 <stevebaker> I think we're keeping up with review load at the moment (HOT template reviews are pulling down our averages ;) )
20:27:40 <sdake_> I think typically projects propose on ml
20:27:44 <sdake_> and ppl vote there so there is a record
20:27:49 <shardy> he's done quite a lot of high-quality reviews lately, sent some nice patches, and has been actively involved day-to-day
20:27:52 <therve> \o/
20:28:01 <zaneb> +1, but I believe this is supposed to happen on the mailing list
20:28:08 <shardy> sdake_: Yes, we'll do the formal thing on the ML too
20:28:26 <shardy> just wanted to check there was consensus since we're discussing heat-core anyway
20:28:34 <sdake_> need more reviewers definately
20:28:37 <stevebaker> sounds good to me
20:28:53 <jpeeler> yep, agreed
20:29:17 <shardy> Ok, I'll send a propose email to openstack-dev later, please add your response there
20:29:23 <radix> yay therve :)
20:29:41 <lifeless> radix: oh hello :)
20:29:43 <therve> Thanks, I'll try to prove worthy! :)
20:29:46 <radix> hello :)
20:29:46 <shardy> Yep, nice work therve, thanks :)
20:30:05 <shardy> #topic Proposal: add public cloud resource types in-tree
20:30:13 <shardy> sdake, was this yours?
20:30:24 <zaneb> I think it was stevebaker
20:30:31 <asalkeld> there is a link
20:30:42 <wirehead_> There was an IRC discussion on the subject that happened mostly in PST-friendly hours
20:30:46 <zaneb> so, by in-tree do we mean /contrib?
20:30:49 <zaneb> if so then +1
20:30:57 <asalkeld> zaneb, no in-tree
20:31:09 <sdake_> asalkeld's shardy
20:31:11 <asalkeld> like first class
20:31:38 <asalkeld> dang, finding link...
20:31:59 <sdake_> its the same link posted above for the action items
20:31:59 <asalkeld> https://wiki.openstack.org/wiki/Heat/on-public-clouds#Proposal_to_keep_Public_OpenStack_cloud_resources_in-tree
20:32:30 <shardy> stevebaker: care to give us a summary of the proposal?
20:32:41 <stevebaker> <stevebaker> I think we should do what the kernel does, encourage plugins to be in-tree by:
20:32:41 <asalkeld> so to me important point is: So not every public cloud on the planet, but rather where there are developers that are actively participating in the Heat commutity.
20:32:44 <stevebaker> 1. not guaranteeing a stable internal api
20:32:46 <stevebaker> 2. committing to updating in-tree plugins whenever internal api does change
20:33:06 <asalkeld> I like that stevebaker +1
20:33:19 <zaneb> +1 on that
20:33:21 <stevebaker> it works for the kernel
20:33:28 <asalkeld> to me better in tree, than out
20:33:30 <SpamapS> What exact example of this are we thinking of?
20:33:32 <sdake_> kernel has a million maintainers
20:33:44 <stevebaker> SpamapS: hpcloud and rackspace
20:34:04 <davidhadas> swift
20:34:04 <sdake_> i believe asalkeld's proposal was essentially to put a hpcloud and rackspace at top of resources directory
20:34:05 <kebray> so, if internal API breaks, there's no guarantee that in-tree resources get updated and will work?  Isn't that the argument for them to be out-of-tree?
20:34:07 <zaneb> otoh we shouldn't be encouraging vendors to have non-compatible OpenStack APIs in the first place
20:34:12 <shardy> I've got no real objection provided they're actively maintained
20:34:20 <sdake_> and let them go wild with a "MAINTAINERS" contact
20:34:20 <shardy> don't want to ship stuff which is broken ;)
20:34:24 <SpamapS> stevebaker: but what special sauce would they have that isn't just "openstack" ?
20:34:45 <zaneb> kebray: 2. committing to updating in-tree plugins whenever internal api does change
20:34:49 <wirehead_> Yeah, if the internal API breaks, we would commit to updating the in-tree resources
20:35:10 <kebray> zaneb: we all know APIs never change :-)
20:35:17 <stevebaker> SpamapS: I would assume that as these public clouds are updated then legacy workarounds could be taken out of our tree
20:35:18 <davidhadas> swift
20:35:21 <sdake_> my only major heartburn with the proposal is we have no way to validate or test it
20:35:28 <davidhadas> (sorry)
20:35:55 <asalkeld> sdake_ they can add special mocks
20:35:56 <stevebaker> sdake, I'd like the tempest tests to be run against different clouds
20:36:00 <shardy> ideally, those contributing these would provide provider-agnostic resources in the main resources area
20:36:13 <shardy> can anyone explain some of the reasons for provider-specific resources?
20:36:17 <wirehead_> Hacks.
20:36:27 <asalkeld> weird auth
20:36:33 <sdake_> no cloudinit
20:36:39 <zaneb> +1 for hacks. +2 for putting them in /contrib
20:36:39 <SpamapS> stevebaker: I guess I'm missing where they need any special "not openstack" things right now. :-P
20:36:44 <asalkeld> and limited implementations?
20:36:50 <kebray> rackspace images don't have cloudinit on them today.
20:37:22 <SpamapS> No cloud-init has its genesis in rackspace, but it could very well be something that other private cloud operators do...
20:37:24 <asalkeld> so shardy my hope is these are short lived
20:37:29 <sdake_> rackspace also has no way to upload images - so  there is no real workaround without rs specific hacks to resources
20:38:12 <asalkeld> sdake_ yea, you have to modify an existing one and "save" it
20:38:20 <SpamapS> sdake_: HP is the same.
20:38:22 <shardy> Ok, not having cloud-init sounds pretty limiting to me, but if that's the status-quo then I guess we go with the hacks dir :)
20:38:23 <wirehead_> I think that the hacks related to simple things like getting images up will hopefully go away, but there's always going to be some potential for vendor-specific magic stuff
20:38:24 <sdake_> just see a future where there are 20 server plugins, 20 storage plugins, 20 different type of quantum plugins etc
20:38:24 <sdake_> becomes especially intrusive if we change around the dsl
20:38:26 <kebray> The workaround is snapshot an image, since you can't upload.
20:38:57 <SpamapS> I don't see this as hacks, but just drivers.
20:39:09 <asalkeld> sdake to me worse if they are out of tree
20:39:25 <asalkeld> (we then need much stronger api versioning)
20:39:37 <shardy> Ok, do we need to start a ML discussion on this?
20:39:39 <SpamapS> Yes agreed, in-tree drivers will stay more useful to more people.
20:39:55 <wirehead_> Do we need to specify more carefully how it would look, so that people can be comfortable with exactly how it's split up?
20:40:02 <asalkeld> me thinking it would make infra's life easier
20:40:14 <stevebaker> lets decide when the first patch lands
20:40:18 <wirehead_> We're mostly nodding in agreement about the base principles.
20:40:44 <shardy> Ok, well lets move on for now, and if necessary follow up on the ML
20:40:52 <shardy> #topic Proposal (sdake): For [rs-dsl] or [open-api-dsl] require +2 from asalkeld, jpeeler, sdake, stevebaker, zaneb with +A from shardy
20:41:04 <sdake_> (and therve possibly:)
20:41:15 <asalkeld> ?
20:41:21 <sdake_> so basic idea here is since dsl is huge change to everything in heat
20:41:24 <sdake_> and we have to live with it
20:41:35 <sdake_> we should all express our agreement in the patch
20:41:39 <sdake_> vs just couple core devs
20:42:01 <SpamapS> Perhaps we just call it a "majority" of devs need to weigh in with +2's?
20:42:06 <zaneb> agree with the rationale
20:42:10 <shardy> So I think this may be a bit hard to manage, I agree everything should be well reviewed but will this make the review cycle unmanageble?
20:42:12 <sdake_> personally I think the new dsl is pretty sweet
20:42:17 <asalkeld> mm, so how do you figure out if a patch is dsl affecting
20:42:19 <SpamapS> I don't want to set a precedent that we all have to agree or even review big decisions.
20:42:24 <sdake_> only for the "first" patch that lands shardy
20:42:47 <zaneb> however, I don't think we should be committing the "end-state" DSL example at all
20:43:00 <zaneb> we should have an example template that evolves with the code
20:43:11 <SpamapS> But I do like the idea that we would step back and not "approve" until at least half of the core team has said +2.
20:43:14 <shardy> zaneb: I completely agree, incremental evolution
20:43:29 <asalkeld> is this for the heat-template patch or code in heat?
20:43:48 <zaneb> asalkeld: I think we're talking about the patch
20:43:49 <sdake_> asalkeld: read the agenda - there are links there
20:44:18 <zaneb> I personally don't see the patch as something that will ever be committed
20:44:18 <therve> As long as we do incremental changes, I don't think there is much to fear about the end result being disliked.
20:44:22 <shardy> Ok, well shall we say that people posting HOT/DSL related patches should add all heat-core to the reviewers list, and that we (heat-core) will make sure things are reviewed by several (more than 2) reviewers before approving?
20:44:27 <zaneb> it's just using Gerrit as a discussion tool
20:44:31 <shardy> I don't need to be the only one to approve IMO
20:44:37 <zaneb> I can -2 now to save time? ;)
20:44:40 <therve> We should probably all pay slightly more attention to those I presume
20:45:04 <kebray> As long as the templates are properly versioned, can't we manage having a rapidly changing (lightweight review) template format in the short run?   that is, we only need to be backwards compatible with the version that yes stamped every 6 months, right?
20:45:13 <zaneb> shardy: +1
20:45:16 <zaneb> kebray: correct
20:45:30 <shardy> therve: Yep, we can just agree to give extra attention (and time) for everyone to get a look at stuff before it's merged
20:45:32 <therve> shardy, In practice how does gerrit support it?
20:45:32 <stevebaker> shardy: +1
20:45:38 <sdake_> kebray as long as they are forward compatible...
20:45:46 <zaneb> I think everyone acknowledges there's a higher bar for consensus when implementing major features
20:46:34 <stevebaker> an example template is just an expression of intent though
20:46:44 <asalkeld> not a spec
20:47:00 <sdake_> so to zaneb's point about not approving the changes, shardy should we banhammer the patch so folks dont inadvertantly merge it ?
20:47:32 <asalkeld> sdake why not merge it and work on it?
20:47:36 * stevebaker has to go
20:47:38 <shardy> sdake_: I guess, but has anyone ever accidentally approved something?
20:47:41 <sdake_> zaneb's idea ;)
20:47:41 <asalkeld> instead of letting it hang
20:48:02 <zaneb> shardy: I accidentally approved something the other day ;)
20:48:11 <shardy> asalkeld: Idea is just to get eyes on the patch before we merge something half the team hate ;)
20:48:21 * sdake_ admits to +2 +A without another +2 recently... groan
20:48:25 <shardy> zaneb: lol
20:48:38 <asalkeld> shardy, sure
20:48:53 <asalkeld> but, we can iterate as well
20:48:56 <clarkb> if you catch yourself before jenkins finishes testing you can remove your +A to prevent merging
20:49:06 <sdake_> clarkb ya i did catch it quickly
20:49:12 <sdake_> and fixed it fortunately :)
20:49:34 <shardy> Ok, well shall we just handle this informally, if there's a patch anyone reviews which they thing is suitably contentious, -2 it and make sure we get consensus before merge
20:49:37 <zaneb> clarkb: I didn't want to be that obvious ;)
20:49:58 <sdake_> zaneb never makes mistakess ;)
20:49:59 <shardy> Fpr obviously OK and simple/small stuff, we use the normal process of 2x+2
20:50:26 <sdake_> shardy : i think for most things that makes sense, the dsl is a special case tho
20:50:28 <asalkeld> shardy, you mean for everything else?
20:50:31 <shardy> I think we can all be trusted with this stuff, but I do agree we should all be extra active reviewing it
20:50:32 <therve> Let's not be afraid of reverts too if that needs to happen.
20:51:15 <shardy> asalkeld: I think we're just saying for big DSL changes
20:51:23 <asalkeld> good
20:51:24 <SpamapS> 9 minutes
20:51:29 <shardy> I've got no desire to extend the review cycle unnecessarily
20:51:43 <sdake_> in fact first one would be good enough to satisfy me :)
20:51:50 <sdake_> after that iterate + normal process
20:51:55 <shardy> #topic How/where to handle HOT in the code
20:52:09 <shardy> So shall we skip this and go to open discussion?
20:52:17 <shardy> since we really covered it earlier?
20:52:20 <zaneb> shardy: yep, we've done that to death
20:52:28 <shardy> #topic Open discussion
20:52:29 <sdake_> i do have one quesiton
20:52:34 <asalkeld> initial Environment patch: https://review.openstack.org/#/c/30866/
20:52:38 <zaneb> sdake_: too late ;)
20:52:41 <sdake_> the open-dsl vs hot - are they competing proposals?
20:52:43 <fsargent> Do y'all have Rackspace accounts yet? How is it going?
20:53:01 <fsargent> If not: http://iopenedthecloud.com/
20:53:03 <zaneb> sdake_: no, they're different names for the same general effort
20:53:05 <asalkeld> thanks fsargent
20:53:12 <shardy> sdake_: No, we're trying to converge on a native syntax which pleases all those who want a non-cfn template model
20:53:13 <sdake_> fsargent I applied but no email yet
20:53:23 <fsargent> okay, I'll knock some heads together.
20:53:27 <zaneb> fsargent: I have the t-shirt, but not the account yet
20:53:34 <asalkeld> ha
20:53:43 <wirehead_> Have the t-shirt, not the account.  That's a metaphor for something
20:54:00 <sdake_> zaneb afraid to go over his 500 mo limit ;)
20:54:08 <asalkeld> fsargent, can we get a racks server resource?
20:54:21 <shardy> asalkeld: nice, will review in the morning :)
20:54:25 <wirehead_> racks server resource?
20:54:44 <asalkeld> a resource that starts a rackspace server
20:54:48 <kebray> racks server, LBaaS, and DBaaS resources for Heat are in the works.
20:54:59 <kebray> asalkeld:  my team is working it right now.
20:55:05 <asalkeld> I just need the server
20:55:11 <asalkeld> (alpha?)
20:55:13 <kebray> Yep.. well, I need all 3 :-)
20:55:19 <sdake_> in h2 the nova resources are changing
20:55:27 <sdake_> so keep that in mind - may hav eto do a bit of rework on your end
20:55:41 <shardy> kebray: feel free to post WIP/draft patches or a fork somewhere, so we can see what you're doing :)
20:55:48 <asalkeld> +1
20:56:01 <kebray> sdake_ don't care about Nova changes, as long as the resource implementation doesn't change.  it'll be one of the vendor specific resources for now.
20:56:12 <SpamapS> small patches that work ho-hum are better than giant patches that "work fine in my rack"
20:56:17 <shardy> 4 minutes, anything else?
20:56:25 <zaneb> random interesting thing I discovered today
20:56:30 <zaneb> #link http://www.pulpproject.org/
20:56:33 <kebray> Yeah, been wondering where the team should dump code.. sort of waiting for the in-tree vs. just stack forge discussion to settle.
20:56:40 <zaneb> in the context of https://wiki.openstack.org/wiki/Heat/htr
20:57:06 <zaneb> apparently puppet are using it for their manifests repo
20:57:11 <zaneb> that is all.
20:57:14 <SpamapS> meh
20:57:28 * SpamapS hugs his image based update dreams tightly.
20:57:39 <asalkeld> har
20:58:09 <sdake_> shardy the "only run non-aws templates" wasn't in the h2 milestone
20:58:15 * kebray hands SpamapS a copy of Good to Great.
20:58:25 <sdake_> the blueprint spamaps wrote up
20:58:38 <shardy> sdake_: the open-api-dsl is the umbrella BP, targetted at h3
20:58:39 <sdake_> we may need that for nova-server blueprint
20:58:58 <shardy> as we have a load of dependent BPs targeted at h2, most of which have not even been started
20:59:03 <shardy> which is a bit worrying
20:59:11 <shardy> but anyway, out of time
20:59:15 <wirehead_> kebray: I haven't heard any major partisan fans of the stack forge approach.  We can negative-vote to say that the rackspace resource ought to live in-tree
20:59:15 <shardy> #endmeeting