20:00:05 <shardy> #startmeeting heat
20:00:06 <openstack> Meeting started Wed Nov  4 20:00:05 2015 UTC and is due to finish in 60 minutes.  The chair is shardy. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:11 <openstack> The meeting name has been set to 'heat'
20:00:17 <shardy> #topic rollcall
20:00:20 <jdob> o/
20:00:21 <shardy> Hi all
20:00:22 <stevebaker> \o
20:00:22 <jdandrea> o/
20:00:24 <ryansb> good aftermorningnoonnight
20:00:41 <shardy> skraynev is out today IIRC so I offered to chair today
20:01:52 <shardy> Ok, let's get started
20:02:08 <shardy> #topic Adding items to the agenda
20:02:14 <shardy> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda
20:02:21 <shardy> Anyone have anything to add?
20:02:49 <stevebaker> short agenda :)
20:03:05 <jdandrea> heh
20:03:14 <shardy> haha
20:03:16 <jdandrea> jetlag stories?
20:03:33 <stevebaker> slept like a baby on the plane
20:03:36 <jdandrea> +1
20:04:09 <shardy> #topic review priorities
20:04:15 <shardy> #link https://etherpad.openstack.org/p/heat-reviews
20:04:31 <stevebaker> that etherpad hasn't been updated in an age
20:04:49 <shardy> I thought it'd be worth reviewing that, particularly post-summit so we can ensure we can focus on general topics
20:04:51 <stevebaker> when we hit RC I switched to using launchpad instead
20:05:07 <shardy> stevebaker: Ok, I wasn't aware of that
20:05:11 <shardy> is it worth reviving it?
20:05:33 <shardy> personally I find the wall of reviews fairly daunting, having general priorities is quite useful
20:05:47 <shardy> if others don't we can skip to open discussion :)
20:05:56 <stevebaker> that could be up to Sergey, or whoever wants to own curating that list
20:05:59 <randallburt> doh. stupid DST
20:06:19 <shardy> stevebaker: Ok, I'll defer that for skraynev to decide
20:06:35 <stevebaker> there we go, its a blank slate now
20:06:42 <shardy> #info skraynev can decide if we track review priorities via etherpad for mitaka
20:06:51 <jdob> for what it's worth, i like the idea of being able to highlight pressing things, like milestone aligned stuff
20:06:55 <jdob> agree on the daunting wall
20:07:47 <shardy> stevebaker: Ok, thanks, lets defer populating it until next week
20:07:53 <shardy> #topic open discussion
20:07:55 <stevebaker> +1
20:08:14 <shardy> anything to raise, or is this going to be a short meeting?
20:08:20 <stevebaker> anybody not at summit want a summary on a particular topic?
20:08:27 <jdob> anyone planning on emailing any summary of summit?
20:09:03 <shardy> jdob: I was considering a blog post or something, but any email summary should probably come from the PTL
20:09:18 <jdob> makes sense
20:09:28 <shardy> action skraynev all-the-things ;)
20:09:31 <randallburt> in the meantime, the eitherpads for the sessions should have some notes on them
20:09:42 <shardy> randallburt: good point! :)
20:09:47 <jdob> good call, and I already followed up with specific people about things I was interested in
20:10:03 <shardy> #link https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads#Heat
20:12:42 <shardy> A heads up, there was a regression which broke the gate today, ramishra found/fixed it
20:12:49 <shardy> #link https://bugs.launchpad.net/heat/+bug/1512937
20:12:49 <openstack> Launchpad bug 1512937 in neutron "CREATE_FAILED status due to 'Resource CREATE failed: NotFound: resources.pool: No eligible backend for pool" [Critical,Fix committed] - Assigned to Rabi Mishra (rabi)
20:13:22 <jdandrea> Thanks ramishra!
20:13:24 <shardy> We can probably un-skip the test now, but it'd be good to ensure there's no other breakage anticipated
20:14:21 <shardy> Another thing is I posted a patch aiming to fix bug #1508115
20:14:21 <openstack> bug 1508115 in heat "StackResource updates can destroy more than is needed" [High,In progress] https://launchpad.net/bugs/1508115 - Assigned to Steven Hardy (shardy)
20:14:31 <shardy> https://review.openstack.org/#/c/238194/
20:15:06 <shardy> zaneb already provided some good feedback, but I'd welcome additional eyes, as it's changing the way we do updates to nested stacks (and TemplateResource in particular)
20:15:20 <shardy> anyone else have anything to highlight?
20:15:36 <zaneb> shardy: actually, I was thinking more about that one
20:15:48 <zaneb> it's wrong to treat TemplateResource as a special case
20:16:23 <zaneb> we should always replace because the resource type resolves to a different *class*, never just because the resource type is different
20:17:36 <shardy> zaneb: Interesting, so in-place updates to the same class or any subclass are valid?
20:17:50 <zaneb> not subclass
20:17:59 <zaneb> but say you have an OS::Nova::Server
20:18:19 <zaneb> and you want to change it to some custom type and map it to OS::Nova::Server in the environment
20:18:21 <zaneb> that's legit
20:18:22 <shardy> zaneb: I was looking at the _needs_update part, and you can't determine the actual class from the resource definition on update, because you don't have the environment of the new stack, only the old one
20:18:43 <shardy> we can fix that by passing more info into needs_update potentially
20:18:48 <zaneb> shardy: ok, so maybe that's not the right place to do it after all
20:19:03 <zaneb> that leaves an open question of how to do it for convergence :/
20:19:54 <shardy> zaneb: actually that OS::Nova::Server example is a good one, I should probably add a functional test where we override a built-in resource with a nested stack returning OS::stack_id
20:20:00 <zaneb> I'll add another comment to the review, we can move on
20:20:15 <shardy> (probably not a server, but an actual resource not only TemplateResource)
20:20:27 <shardy> zaneb: Ok, thanks
20:20:32 <shardy> anything else anyone?
20:22:07 <shardy> Ok then, short meeting ;)
20:22:09 <ryansb> *cricket sounds*
20:22:13 <shardy> thanks all
20:22:15 <jdob> \o
20:22:16 <ryansb> \o
20:22:17 <shardy> #endmeeting