20:00:10 <stevebaker> #startmeeting heat
20:00:11 <openstack> Meeting started Wed Oct 16 20:00:10 2013 UTC and is due to finish in 60 minutes.  The chair is stevebaker. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:14 <openstack> The meeting name has been set to 'heat'
20:00:29 <stevebaker> #topic rollcall
20:00:35 <shardy> o/
20:00:37 <asalkeld> o/
20:00:40 <tspatzier> hi
20:00:52 <jpeeler> hey
20:00:54 <spzala> hi
20:00:59 <m4dcoder_> o/
20:01:07 <bgorski> o/
20:01:16 <randallburt> o/
20:01:18 <kebray> \o
20:01:50 <jlucci> \o/
20:01:53 <stevebaker> no zane, must be enjoying paris
20:02:14 <stevebaker> #topic Review last week's actions
20:02:26 <andrew_plunk> o/
20:02:26 <stevebaker> http://eavesdrop.openstack.org/meetings/heat/2013/heat.2013-10-09-20.00.html
20:02:34 <stevebaker> looks like no action items, that was easy!
20:02:55 <stevebaker> #topic Havana release status
20:03:07 <stevebaker> shardy: would you like to give an update?
20:03:21 <shardy> So RC2 is out, only critical release blockers will trigger another RC now
20:03:42 <shardy> Please keep testing, and tag any potential release blocker bugs with havana-rc-potential
20:03:47 <stevebaker> nice, well done everyone
20:04:07 <shardy> other less critical stuff can be havana-backport-potential, and we'll handle it it the next stable/havana release
20:04:14 <shardy> Yup, great job all! :)
20:04:18 <jasond> o/
20:04:50 <stevebaker> #topic release notes
20:04:56 <stevebaker> #link https://wiki.openstack.org/wiki/ReleaseNotes/Havana#OpenStack_Orchestration_.28Heat.29
20:05:05 <stevebaker> #link https://etherpad.openstack.org/p/heat-havana-release-notes
20:05:15 <stevebaker> shardy has started updating the wiki
20:05:20 <shardy> So I made a start on the wiki
20:05:27 <stevebaker> I did some stuff on the etherpad earlier
20:05:38 <stevebaker> shardy: did you base that on the etherpad?
20:05:41 <sdake_> o/
20:05:44 <asalkeld> etherpad not happy
20:05:52 <asalkeld> won't connect
20:05:53 <stevebaker> try refreshing
20:05:58 <shardy> stevebaker: actually not really..
20:06:10 <shardy> stevebaker: I'll take an action to sync etherpad with wiki
20:06:24 <SpamapS> o/
20:06:46 <shardy> #action shardy to sync Havana release notes etherpad with wiki
20:07:00 <stevebaker> the etherpad has a few more practical details in the upgrade notes
20:07:39 <shardy> Ok, cool, thanks
20:07:45 * SpamapS adds a few details on the limits added
20:07:56 <stevebaker> should we be detailing interesting new configuration options?
20:08:21 <radix> oops, here
20:08:38 <shardy> I think put as much detail as you like in the etherpad, and if it's getting too much, I'll link it from the wiki
20:08:46 <sdake_> stevebaker I think that might be a little much
20:09:03 <stevebaker> I guess that detail should go in the install guide
20:09:08 <sdake_> agreed
20:09:16 <asalkeld> major issue is did we remove any
20:09:27 <asalkeld> (config options)
20:09:30 <shardy> We want to capture the info somewhere tho, while we still remember the details :)
20:09:41 <sdake_> shardy that is what the git is for ;)
20:09:55 <stevebaker> trawling the git history of heat.conf.sample is pretty useful
20:09:57 <shardy> I say add it to the wiki, and I'll pick the highlights for the wiki
20:10:05 <shardy> at least then it's written down
20:10:32 <sdake_> what would be interesting is a listing of all config options
20:10:33 <shardy> sdake_: A lot of users won't want to trawl git to get overview info IMO
20:10:36 <sdake_> i guess thats the install guide
20:10:49 <shardy> sdake_: You mean like heat.conf.sample?
20:10:59 <sdake_> does that have all of them?
20:11:05 <shardy> sdake_: yup
20:11:08 <sdake_> nm then
20:11:26 <shardy> sdake_: that's the cool thing, it's sync'd via a script now
20:11:37 <shardy> well you have to run the script, but..
20:12:23 <SpamapS> TO me release notes are "here is what might not be obvious about the new release"
20:12:45 <shardy> SpamapS: Yeah, that's what needs to end up in the wiki
20:12:55 <shardy> SpamapS: but we can pool info in the etherpad to get there :)
20:13:13 <SpamapS> Yes, put it all in the etherpad and then put summaries of things in the actual release notes.
20:13:20 <shardy> +1
20:13:32 <stevebaker> Yes, if you've implemented blueprints or features, you're probably the best person to write the release notes to draw attention to them
20:13:48 <SpamapS> like we don't have to say the actual config limits that were added, but "Several configuration options were added to limit user impact on the heat engine service." works.
20:14:28 <stevebaker> #topic Summit session proposals
20:14:44 <stevebaker> #link http://summit.openstack.org/
20:15:06 <sdake_> holy cripola
20:15:08 <SpamapS> so many
20:15:11 <stevebaker> Click on the Topic column twice to make it reverse order, then scroll down
20:15:11 <sdake_> heathas like 20 sessions
20:15:29 <stevebaker> We have 9 slots and 19 session proposals
20:16:29 <sdake_> stevebaker the web ui should allow you to merge sessions
20:16:30 <kebray> Any hope of running two tracks?
20:16:41 <kebray> guessing we only have one room.
20:16:44 <sdake_> or give folks half time for one session
20:16:53 <stevebaker> I don't have teh powerz to review sessions yet
20:17:05 <stevebaker> but will ask
20:17:10 <shardy> stevebaker: I do, we can coordinate
20:17:14 <sdake_> ya recommend getting soon running out of time
20:17:50 <stevebaker> I don't think an optimal program can be built by committee, so I'll be doing some merging and culling then will be asking for further feedback just in case anyone thinks their topic is under represented
20:18:23 <radix> OK
20:18:35 <kebray> stevebaker there was an ether pad that had started some of the organizational notes... I'll look for the link.
20:18:50 <stevebaker> #link https://etherpad.openstack.org/p/heat-icehouse-summit-proposals
20:18:52 <kebray> https://etherpad.openstack.org/p/heat-icehouse-summit-proposals
20:19:12 <radix> I kinda think the summit isn't going to scale well for all the discussion that needs to happen.
20:19:19 <SpamapS> stevebaker: I'm sure a few of those can be solved with ML discussions.
20:19:45 <stevebaker> some smaller topics might get merged into other sessions, with strict time limits
20:19:54 <radix> what do you guys think of g+ hangouts?
20:20:12 <asalkeld> for what?
20:20:14 <sdake_> radix asalkeld would have to brush his hair
20:20:23 <SpamapS> sessions are for "we need to get in a room and talk about the impact/ideas/etc". Some of those sessions are going to get a JFDI from all of us if proposed on the ML.
20:20:25 <stevebaker> so yes, put any thoughts in the etherpad or the summit session comments
20:20:28 <shardy> radix: prefer ML as it's persistent, and more inclusive
20:20:45 <radix> hehe :) well video isn't required
20:21:03 <SpamapS> shardy: G+ hangouts can be saved as youtube videos
20:21:16 <radix> right, and we can take minutes
20:21:21 <shardy> SpamapS: but they're limited participation
20:21:31 <SpamapS> but they are exclusive of sleeping timezones
20:21:37 <radix> basically ml has not been as effective as I hoped for certain conversations
20:21:41 <stevebaker> any new resources or updating resources for new features will be JFDI, so sessions might not be necessary for them unless it is to divvy out responsibility
20:21:56 <SpamapS> shardy: I think there are plenty of things that don't need more than 10 speakers.
20:22:06 <radix> like we still need more discussion in the AS/LB thread
20:22:29 <SpamapS> The ML should be the first place to discuss though.
20:22:29 <radix> but I guess I just need to make more noise
20:22:31 <asalkeld> also there are other slots we can using in the week
20:23:02 <SpamapS> If it feels like the issue is too contentious to discuss in a faceless ML manner, then hangouts are a viable option IMO.
20:23:02 <shardy> SpamapS: I'm not against that, I just think ML first, and with the summit only a couple of weeks away, I figure we can discuss most stuff there
20:23:05 <asalkeld> radix, you can always bug me on g+ if you want
20:23:15 <shardy> even if it's over beer rather than in the sessions
20:23:17 <stevebaker> does anyone have session proposals they haven't got around to submitting yet?
20:23:29 <SpamapS> Yeah, beer/breakouts/etc.
20:23:33 <shardy> yup
20:23:34 <radix> OK
20:23:59 <SpamapS> I like to exhaust all other means before the summit though, so the summit is just the stuff we really do need face time for.
20:23:59 <radix> man, I'm sad I'm not going. but I won't miss the flying :)
20:24:21 <stevebaker> radix: oh, I thought you were
20:24:25 <shardy> stevebaker: I did consider one re auth stuff, but I think I've pretty much got that under control now
20:24:41 <shardy> basically fix-all-the-keystone-things
20:25:18 <stevebaker> radix: maybe I assumed you were because you've proposed 2 sessions ;)
20:25:39 <SpamapS> I do have an idea forming that I will need probably in the icehouse timeframe.. but I'm not sure I'll have it fleshed out enough before the summit to talk about it there.
20:25:43 <radix> hehe, yeah. Thomas and Randall should be able to cover for me
20:25:53 <stevebaker> cool, ok
20:26:05 * randallburt will be radix for the summit
20:26:11 <SpamapS> It involves update flow control at a somewhat lower level than the rolling update proposal I also hope to discuss.
20:26:17 <SpamapS> err
20:26:17 <stevebaker> radixalburt
20:26:24 <SpamapS> rolling update proposal I salso hope to implement :-P
20:27:05 <stevebaker> SpamapS: beer track, if nothing else
20:27:21 <SpamapS> aye
20:28:13 <stevebaker> I'll aim to have a list of 9 for next week's meeting so we can actually go through each proposed session
20:28:31 <sdake_> sounds good stevebaker
20:28:34 <stevebaker> #action stevebaker to review all summit proposals and reduce to 9 sessions
20:28:52 <stevebaker> anything else on summit?
20:28:58 <asalkeld> stevebaker, maybe also make a list for extra slots
20:29:11 <sdake_> asalkled idea is to combine sessions where possible
20:29:19 <SpamapS> stevebaker: if we can actually only have 8 defined before hand..
20:29:22 <asalkeld> there are ones you can sign up for
20:29:39 <SpamapS> stevebaker: never fails by the 3rd session we have a need for another.
20:29:44 <asalkeld> breakout rooms I think they call them
20:30:20 <stevebaker> asalkeld: I assume there will be some kind of whiteboard signup for breakouts - maybe we should leave that for submitters if they think the session is needed
20:30:21 <asalkeld> we will need more for hot + software config
20:30:58 <asalkeld> sure
20:31:06 <SpamapS> Its a bit of a surprise to me that we are limited to 9. At ubuntu dev summits, there were always at least 4 empty slots per track.
20:31:24 <stevebaker> SpamapS: yeah, maybe 8 + 1 for topic overflow
20:31:52 <SpamapS> By day 2 they're all filled (and not with breakout type stuff.. with "doh we forgot about that we need to talk to everybody about this")
20:32:12 <SpamapS> anyway, I understand if it isn't possible, but just a thought. :)
20:32:50 <stevebaker> #topic HOT software configuration
20:33:12 <stevebaker> I sent out an email yesterday with
20:33:14 <stevebaker> #link https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config
20:33:18 <stevebaker> and
20:33:24 <stevebaker> #link https://wiki.openstack.org/wiki/Heat/Blueprints/native-tools-bootstrap-config
20:33:53 <asalkeld> I also made one #link https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-42
20:34:09 <stevebaker> maybe the ML is the best place to continue that discussion, but if there are things to discuss in realtime then now is a good chance
20:34:27 <sdake_> whats with the 42
20:34:30 <sdake_> meaning of life? :)
20:34:36 <randallburt> the universe?
20:34:38 <asalkeld> shrug
20:34:55 <SpamapS> sdake_: 6*7
20:34:57 <stevebaker> and there will be (at least) a summit session about this, but it would be nice if we were some way down the track in reaching a consensus
20:35:02 <asalkeld> doesn't really matter, just splating some ideas down
20:35:32 <SpamapS> I think the ML discussion is going well and your proposal has definitely helped guide the discussion with actual concrete examples.
20:35:51 <lrengan> If there is interest I would like a discussion about cross-vm synchronization and data exchange
20:36:18 <lrengan> stevebaker: I really like several elements of your proposal
20:37:10 <stevebaker> lrengan: I do think that is out of scope for those blueprints, but it is the next Big Problem to solve
20:37:11 <lrengan> I am wondering the possibility of including a higher-level synchronization construct
20:37:36 <sdake_> use case?
20:37:41 <lrengan> in the ML there seems to some consensus emerging about this
20:38:04 <SpamapS> my feeling on that is that it can easily be implemented as a standalone service and would be extremely useful even without Heat.
20:38:20 <stevebaker> The thing is, everybody who has implemented their own orchestration has an opinion on this - and that seems to be a lot of people ;)
20:38:46 <asalkeld> we can't just add features from all  of them
20:38:54 <asalkeld> else we will have a mess
20:39:09 <lrengan> SpamapS: I agree it can be implemented as a separate service, but I think if Heat is serious about support software config it has have some mechanisms that it can reason about
20:39:12 <SpamapS> agreed, we can, however, add an interface which all of them can implement. :)
20:40:05 <lrengan> Heat picks an order for creation of resources and if the ordering and synchronization among the software is not exposed to Heat
20:40:34 <tspatzier> I think we need to define the core primtives that have to be added to Heat / HOT to support that potential higher-level service, and which would work for other such implementations as well
20:40:54 <asalkeld> lrengan, I think you need to flesh out how this would look in Heat
20:41:11 <asalkeld> what would a template look like
20:41:24 <asalkeld> what code changes would be needed etc..
20:41:25 <stevebaker> but also how it would be implemented
20:41:36 <m4dcoder_> and using a concrete example in the template
20:41:40 <shardy> asalkeld: I agree, concrete example, interfaces and proposals for features are what we need atm
20:41:53 <lrengan> yes, I can provide those details.
20:41:55 <SpamapS> I have some ideas how it could look in HOT using Steve's component system. As Zane alluded to though, it shouldn't be "here's how Puppet talks to Heat" but "here's a handle random thing. Hit me with my API there."
20:41:58 <tspatzier> yes, lrengan can you draft a template that shows the element you think would be needed in a template?
20:41:59 <asalkeld> at the moment it is really hard to figure out what you suggestion is really
20:42:16 <lrengan> I do have an prototype implementation with some info captured in the metadata section in Heat
20:42:23 <lrengan> the prototype uses zookeeper
20:42:29 <sdake_> ugh
20:42:42 <lrengan> However, neither of these choices are required
20:42:46 <asalkeld> so lrengan we support Heat in standalone
20:43:03 <asalkeld> where heat is not installed in the cloud
20:43:12 <lrengan> there are several alternatives one can pursue … for example, replace zookeeper by the heat metadata service
20:43:26 <asalkeld> we might also want to support multi cloud
20:43:32 <asalkeld> just keep that in mind
20:43:34 <sdake_> good, i am really negative about zookeeper as a dependency
20:43:37 <shardy> lrengan: you mean heat resource metadata?
20:43:40 <SpamapS> For me, I struggle to think of a deployment that doesn't have a 3 part initialization sync that looks something like this: "create it. tell other side about it. enable access for other side to it"
20:43:44 <shardy> there is no heat metadata service anymore
20:43:57 <SpamapS> not necessarily in that order :)
20:44:19 <sdake_> SpamapS I think that requires an agent on both ends to configure the nodes
20:44:38 <sdake_> eg runtime config
20:44:44 <lrengan> shardy: yes heat resource metadata is what I used for the proof-of-concept prototype
20:45:13 <shardy> lrengan: Ok, details of what you're doing would be interesting (to the ML)
20:45:18 <SpamapS> sdake_: it doesn't if you can feed access details in from Heat.
20:45:31 <stevebaker> lrengan: it would be interesting if you could adapt what you've done to my components proposal
20:46:21 <lrengan> stevebaker: in fact, that is exactly what I was doing since morning … trying to see how it can fit into your components proposal
20:46:22 <lrengan> :)
20:46:30 <SpamapS> anyway, lets keep the ball rolling on the mailing list, I think it has gone well, and we should continuet hat discussion there.
20:46:32 <stevebaker> should we put a pin in this for now?
20:46:44 <stevebaker> #topic Open discussion
20:47:00 <stevebaker> get amongst it
20:47:52 <SpamapS> just to spitball this idea..
20:48:11 <stevebaker> SpamapS has the talking stick
20:48:12 <SpamapS> We've been looking at how to upgrade openstack using images..
20:48:39 <SpamapS> So there's a case where we might have 20 nodes, and we just want Heat to replace them when we change the image..
20:48:52 <SpamapS> BUT, we want the replacement to proceed like this:
20:48:56 <SpamapS> * create new one
20:49:05 <SpamapS> * wait for new one to signal that it is ready
20:49:11 <SpamapS> * delete old one immediately
20:49:29 <SpamapS> We can't delete all of the old ones at the end, because hardware is expensive.
20:49:51 <SpamapS> But we don't want to delete the old one until it is actually ready.
20:50:21 <SpamapS> It is related to rolling updates.. as rolling updates will end up using the same mechanism. But.. well, does anybody else want it to work this way?
20:50:34 <m4dcoder_> compose an instance group dynamically and then set update policy with batch size of 1
20:51:31 <SpamapS> how does that wait for the ready signal?
20:52:19 <lrengan> is this a case for a construct/feature like "replace" ?
20:52:21 <m4dcoder_> yes, zane proposed to put a bp on something similar to wait for any waitcondition before next batch.
20:52:43 <stevebaker> SpamapS: maybe that is another use for the new sync/messaging, and we can have some implicit messages for compute events (config starting, config done)
20:52:57 <lrengan> replace = create new one + wait for a signal from new one + delete old one
20:53:32 <SpamapS> stevebaker: I could do it relatively easily with just wait conditions as long as there is a way to zero them out on updates.
20:54:03 <SpamapS> (which, there is.. just tweak the properties and/or name to replace it each time)
20:54:46 <SpamapS> anyway, I will take the large scale silence as "haven't thought about it" and bring it up on ML soon when I'm more ready to discuss.
20:54:55 <SpamapS> that is all from me
20:55:04 <stevebaker> sounds like a valid use case
20:55:04 <lrengan> the deleted machine .. would you be reusing it again in the same deploy?
20:55:16 <lrengan> if so don't need to make sure the delete is complete too?
20:55:26 <SpamapS> lrengan: that is nova's job.
20:55:46 <SpamapS> it isn't available again in the pool until the nova driver has said the machine is deleted.
20:56:00 <lrengan> ok, got it.
20:57:17 <stevebaker> SpamapS: do you know if a waitcondition gets reset on server replace currently?
20:58:19 <lrengan> SpamapS: just curious: how do you handle errors for such updates?
20:59:43 <stevebaker> time to move this to #heat. Thanks everyone!
20:59:52 <stevebaker> #endmeeting