20:00:24 <skraynev_> #startmeeting heat
20:00:25 <openstack> Meeting started Wed Nov 18 20:00:24 2015 UTC and is due to finish in 60 minutes.  The chair is skraynev_. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:29 <openstack> The meeting name has been set to 'heat'
20:00:35 <skraynev_> #topic rollcall
20:00:38 <stevebaker> \o
20:00:39 <prazumovsky> hi!
20:00:40 <tspatzier> hi
20:00:40 <jdandrea> \o
20:00:43 <shardy> o/
20:00:48 <rpothier> o/
20:01:50 <skraynev_> ok. let's start
20:02:01 <stevebaker> zaneb: ping
20:02:09 <zaneb> o/
20:02:15 <zaneb> thanks
20:02:16 <skraynev_> #topic Adding items to agenda
20:02:27 <skraynev_> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282015-11-18_2000_UTC.29
20:03:28 <skraynev_> agenda looks full
20:04:05 <skraynev_> #topic Review priorities
20:04:20 <skraynev_> #link https://etherpad.openstack.org/p/heat-reviews
20:04:29 <stevebaker> skraynev_: Can we add: Voting status of convergence gate
20:04:45 <skraynev_> stevebaker: sure
20:05:12 <zaneb> ooh, yeah. it looks so close
20:05:22 <skraynev_> stevebaker: done
20:07:00 <skraynev_> zaneb: I am not sure, but huangtianhua has two patches for mentioned bug
20:07:18 <skraynev_> zaneb: could you review and leave comment on it ?
20:07:51 <zaneb> skraynev: did already. one is for delete, one for update. I handled both (+ a few other operations) in my patch
20:08:13 <skraynev_> zaneb: bravo ;)
20:08:26 <zaneb> we should probably look at other improvements (including the ones in huangtianhua's patches) as well
20:08:40 <zaneb> but they're not urgent to resolve the bug
20:09:46 <skraynev_> zaneb: thank you for the note, because I start thinking, that both patches should be abandoned.
20:10:28 <zaneb> yeah, as I said in the comment it's a two-pronged approach
20:10:44 <zaneb> fix the bugs where we are not handling exceptions appropriately
20:11:14 <zaneb> but top priority is to make sure we don't leave the user in the lurch, no matter how badly we screw up the exception handling
20:11:56 <skraynev_> zaneb: ok. got it . thx ;)
20:11:59 <skraynev_> According etherpad we have two the most important things: new API for outputs and openstack-client integration
20:13:08 <skraynev_> so review are welcome ^
20:13:24 <skraynev_> #topic Voting status of convergence gate
20:13:47 <skraynev_> @stevebaker: ^_^
20:14:42 <skraynev_> hm ...
20:14:43 <stevebaker> we may or may not be close to having that job pass, but its been failing for long enough that I think we really need to skip the failing tests and make it voting now
20:15:09 <stevebaker> because currently we risk landing convergence regressions which don't get noticed
20:15:24 <stevebaker> we can unskip tests as they pass
20:15:51 <skraynev_> how about landing these queue https://review.openstack.org/#/c/241973/
20:15:51 <zaneb> stevebaker: I looked the other day
20:15:52 <skraynev_> ?
20:16:00 <zaneb> and all the tests are failing for the same reason
20:16:09 <zaneb> timeout on delete of an autoscaling group IIRC
20:16:27 <zaneb> that suggests to me that we only have 1 bug left to fix
20:16:57 <skraynev_> zaneb: I'd think in favor of 2
20:17:08 <stevebaker> oh, cool. in that case I withdraw my suggestion :D
20:17:42 <skraynev_> zaneb: just according last Anant's comment for patch
20:17:49 <zaneb> ah, yeah
20:17:58 <zaneb> so https://review.openstack.org/#/c/238194/5 added a new test
20:18:09 <zaneb> for which we already have a convergence bug
20:18:35 <zaneb> https://bugs.launchpad.net/heat/+bug/1513233
20:18:35 <openstack> Launchpad bug 1513233 in heat "Convergence doesn't check resource types on update" [Medium,New] - Assigned to Rakesh H S (rh-s)
20:18:49 <zaneb> so we should probably skip that one
20:19:15 <skraynev_> stevebaker: I'd like to create some target - like make voting convergence at the end of the next week
20:19:29 <skraynev_> just need more focused review for this
20:19:35 <stevebaker> skraynev_: +1, either by fixing or skipping
20:19:55 <skraynev_> zaneb: agree.
20:21:09 <skraynev_> #action : skraynev sync with HP guys for making convergence job voting to the end of the next week
20:21:36 <skraynev_> ok. next one:
20:21:51 <skraynev_> #topic: Cleaning specification repository
20:21:57 <skraynev_> therve: around?
20:22:39 <skraynev_> looks like - no
20:22:55 <skraynev_> so I will try to explain topic
20:23:23 <skraynev_> currently we have several specification, which are already merged , but not implemented
20:23:41 <skraynev_> the idea is to make some cleaning for such specifications
20:23:50 <skraynev_> possible solutions:
20:23:55 <skraynev_> 1. remove it
20:24:07 <skraynev_> 2. make like for nova specification
20:24:27 <skraynev_> i.e. have a list of implemented and not implemented for each release
20:24:51 <skraynev_> 3. have one global scope of specification, which are not implemented
20:25:20 <skraynev_> and when one of them is  implemented/finished move it to specific release
20:25:35 <shardy> I think (2) makes most sense, there will always be things proposed which don't get done
20:25:58 <randallburt> fwiw I like 3. It seems odd to pop it into a release folder if its not actually in that release
20:25:58 <shardy> but we don't want to completely remove ideas which were presumably good enough to merge a spec for
20:26:32 <shardy> I suppose a (4) is to move all non-implemented specs around rc time
20:26:43 <skraynev_> shardy: yeap, I agree, that #1 is the worst choice
20:26:45 <shardy> when we know they won't get done, e.g into $release+1 folder
20:26:56 <zaneb> I kind of like 3
20:27:01 <zaneb> agree we don't want 1
20:27:30 <randallburt> yeah, have a heat-next or proposed folder where we put new ones or ones not implemented.
20:27:32 <zaneb> I guess downside of 3 is that links break when it hits a release
20:27:35 <zaneb> that would suck
20:27:47 <shardy> Related to this, we could probably do with some way to find volunteers for things which have been proposed, then folks have moved on
20:27:56 <randallburt> zaneb:  can't we just fix the links when we move them?
20:27:59 <skraynev_> shardy: there is only one potential issue, which was mentioned by therve: implementation some spec not in the current release, i.e. in the next of after the next release
20:28:17 <stevebaker> 4 sounds reasonable, just roll over the specs to the next version.
20:28:19 <zaneb> randallburt: it depends who has linked to them, so I would have to say no
20:28:32 <randallburt> oh, externally linked, gotcha
20:28:32 <shardy> zaneb: can we handle that by decoupling specs from blueprints in launchpad (which would still be release orientated)?
20:29:02 <shardy> zaneb: Oh, sorry you mean HTTP links to the spec, I misunderstood
20:29:41 <zaneb> sorry, apparently my statement was extremely vague ;)
20:30:02 <zaneb> my bad
20:30:06 <shardy> zaneb: heh, it's been a long day ;)
20:31:37 <shardy> Whatever we do I like the idea of having a rolling list of "proposed but not implemented", somewhere
20:31:55 <skraynev_> shardy: do I correctly understand, that due to links issue we can not have some global scope for specs ?
20:31:55 <shardy> as it makes it easier to track when something is stalled and needs a new assignee
20:32:00 <zaneb> shardy++
20:32:41 <zaneb> honestly, I would be happy to have one namespace for all specs and then use launchpad to determine which release they're in
20:32:54 <stevebaker> whatever we adopt we could always have stub specs which link to their final home.
20:32:56 <shardy> skraynev_: I think the problem is only if we move them, as $someone might have a link to them
20:33:15 <shardy> doesn't seem like a huge issue to me, but having a flat specs tree sounds OK
20:33:46 <stevebaker> zaneb: some projects are ditching launchpad for tracking bp milestones and replacing it with... a gerrit based thing?
20:33:57 <zaneb> orly?
20:34:12 <stevebaker> afaik
20:34:30 <zaneb> I thought infra's magic new tracking tool, whatever its called, was going to be the launchpad replacement
20:34:42 <shardy> storyboard
20:34:47 <zaneb> yeah, that one
20:34:54 <stevebaker> storyboard is dead
20:34:59 <jdandrea> Storyboard - I was wondering what happened to that.
20:35:04 <skraynev_> stevebaker: yeah, unfortunately
20:35:12 <stevebaker> some php tool may replace launchpad for *bugs*
20:35:23 <jdandrea> So keep calm and carry on launchpad/etc.?
20:35:28 <shardy> Honestly, I'd be quite happy to just have a status section of the spec "Available in: $release" etc
20:35:37 <shardy> if we have a flat spec tree
20:36:04 <stevebaker> but blueprints are unique, because launchpad really doesn't add much value there
20:36:23 <shardy> I remember granular tracking of status via LP being a big thing for release meetings, is that still the case?
20:36:28 <randallburt> shardy:  +1
20:36:41 <zaneb> shardy: who cares what release it's available in? tracking that is so not what specs are for
20:36:50 <stevebaker> shardy: no, because tere are no release meetings anymore ;)
20:37:25 <skraynev_> shardy, zaneb: how about mixed approach: one namespace for all specs, and separate directories for each release, with one doc which has links with references on implemented specs in this release
20:37:26 <skraynev_> ?
20:37:39 <shardy> zaneb: I'm saying if we didn't have/use launchpad, that would be a way to track it
20:37:40 <skraynev_> stevebaker: WHAT?!
20:37:54 <skraynev_> about release meetings
20:38:04 <stevebaker> skraynev_: oh, are there release meetings?
20:38:11 * jdandrea sound of record scratching to a halt
20:38:24 * stevebaker is not sure of the evolving big tent process
20:38:40 <skraynev_> stevebaker: I thought -yes... but I missed last two
20:38:48 <shardy> stevebaker: Yeah, I knew the big meeting stopped, I assumed there were still 1-1 chats with $release_manager
20:38:55 <zaneb> skraynev_: sounds reasonable to me
20:39:11 <stevebaker> skraynev_: there is the project meeting, but that doesn't cover release topics these days
20:39:25 <stevebaker> and there wasn't one yesterday because there was no agenda
20:39:40 <shardy> Anyway, sorry, I wish I'd never conflated milestone/release tracking and specs now ;)
20:39:48 <Jokke_> the release team meeting is at Fridays iirc
20:39:52 <skraynev_> stevebaker: oh... I see.
20:39:56 <Jokke_> if anyone needs something from them
20:40:21 <skraynev_> Jokke_: ok. which time ?
20:40:36 <stevebaker> shardy: no 1-1 chats anymore, its up to projects to keep their launchpad in order, and say when they are ready for milestone releases
20:41:04 <Jokke_> skraynev_: I think it was 1400 utc, but please check from the meeting list as I might be wrong
20:41:08 <skraynev_> shardy, stevebaker, randallburt: so what's about last idea for specs structure?
20:41:11 <shardy> stevebaker: cool, thanks for the clarification
20:41:19 <stevebaker> everyone should read this
20:41:21 <stevebaker> #link https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg67125.html
20:41:29 <shardy> skraynev_: I'm +1 on anything which doesn't remove them completely
20:41:45 <skraynev_> stevebaker: sounds cool
20:41:57 <skraynev_> shardy: ok.
20:42:47 <skraynev_> #action skraynev or somebody else send mail and start re-organization for specs repository according last suggestion
20:43:18 <skraynev_> #topic: Status of https://launchpad.net/heat/+milestone/mitaka-1
20:43:36 <skraynev_> it's about first milestone status
20:43:57 <stevebaker> zaneb: ah, that mail ^ describes reno as the replacement for using launchpad for tracking blueprints
20:43:59 <skraynev_> we have two weeks before it, as I understand
20:44:11 <zaneb> stevebaker: yeah, reading now :)
20:44:47 <zaneb> wow, milestone-1 always comes up so fast
20:45:18 <skraynev_> 3 December as I see, may be I look on wrong date ;)
20:46:36 <zaneb> #link https://wiki.openstack.org/wiki/Mitaka_Release_Schedule
20:46:40 <zaneb> you're not wrong
20:47:26 <skraynev_> oh.. then need to start moving bugs and specs ;) or finishing them
20:48:20 <skraynev_> also we have a lot of unassigned bugs
20:48:41 <skraynev_> so do not hesitate to fix them ;)
20:50:18 <skraynev_> last one topic and 10 minutes for it ;)
20:50:31 <jdandrea> Will try to keep it brief. ;)
20:50:34 <skraynev_> #topic: RFC on https://bugs.launchpad.net/heat/+bug/1516807 and possible approaches
20:50:35 <openstack> Launchpad bug 1516807 in heat "Nested resources missing orchestration UUID at lifecycle plugin time" [Undecided,New] - Assigned to Joe D'Andrea (joedandrea)
20:50:39 <jdandrea> First: This is the first time I've ever added to the agenda. If it's not an appropriate item, no worries. I can broach it on #heat.
20:51:07 <stevebaker> ban him!
20:51:10 <jdandrea> lol
20:51:13 <jdandrea> Nooooo!
20:51:16 * jdandrea cowers
20:51:41 <skraynev_> jdandrea: you have a big audience, so I think it's good chance ...
20:51:45 <jdandrea> Alrighty then.
20:51:51 <jdandrea> Doesn't have to be solved here, ofc. ...
20:52:23 <jdandrea> So I'm running into a weird situation with UUIDs (not id, but uuid, in a resource)
20:52:34 <jdandrea> These are used, AFAIK, for convergence. *thumbs up*
20:52:37 <zaneb> jdandrea: so what I'd like to ask is how exactly you're using them
20:52:43 <jdandrea> zaneb: Sure.
20:52:46 <zaneb> these are the resource uuid's I gather
20:53:06 <jdandrea> Yes, not the physical ids. These are created before instantiation.
20:53:12 <jdandrea> When a resource is persisted.
20:53:22 <zaneb> as in, the ones that the random suffix on autogenerated resource names are calculated from
20:53:28 <zaneb> ack, gotcha
20:53:47 <jdandrea> Ah, ok. ("The More You Know" - whooosh - U.S. humor)
20:53:51 <jdandrea> I'm using stack lifecycle plugins.
20:54:28 <jdandrea> And one of the things I'm doing (which I finally got open source approval on - yaaaay) concerns scheduling an entire stack of resources vs. one at a time.
20:55:23 <jdandrea> Heat is key since it handles stacks (heh). In the lifecycle plugin, we can look at all the resources, do the scheduling holistically, persist the answers, and then downstream we place them the usual way (even if you use nova/cinder directly, we can still do it, but I digress).
20:55:26 <zaneb> pretty sure that's why mspreitzer & friends added those plugins :)
20:55:31 <jdandrea> So I've been using monolithic templates.
20:55:43 <jdandrea> When I preview the resources I get UUIDs. This is great because it's easy to key to those.
20:55:51 <jdandrea> The other day I finally got around to nested stacks.
20:55:53 <jdandrea> And ...
20:55:54 <jdandrea> oops.
20:56:08 <jdandrea> Those have no UUIDs! Reason: They aren't yet persisted (I think).
20:56:31 <zaneb> right, because they're not created until they're... created
20:56:38 <jdandrea> So I started thinking ... is there a way to have those calculated ahead of time, and you'll see my bullets in that bug. The first two are throwaway.
20:57:11 <jdandrea> The third one is what i'm wondering about, to see if it's even remotely plausible, or if there are ideas I haven't thought of.
20:57:23 <jdandrea> Again, not to solve it here, but just to raise it as a question.
20:57:37 <zaneb> it's at least plausible, I think
20:57:43 <stevebaker> jdandrea: you could always create the resource uuid early, and store the physical id as resource data. Its a shame not to treat the physical id as the resource id but not terrible
20:57:55 <zaneb> certainly for anything inheriting from stack_resource
20:58:01 <skraynev_> jdandrea: heh. may be use openstack dev for gathering more ideas and suggestions ?
20:58:08 <zaneb> (i.e. not OS::Heat::Stack, but all other kinds of nested stacks)
20:58:24 <jdandrea> stevebaker: I didn't think I could do that, actually. I thought that was a no-no.
20:58:50 <zaneb> let's not add anything else to resource_data
20:58:57 <jdandrea> stevebaker: I'd love to treat the physical id as the uuid (what I've taken to calling the orchestration id vs. physical id), but the resource definition hasn't reached nova/cinder/et. al yet.
20:59:08 <jdandrea> skraynev_: I'm all for that. :)
20:59:24 <jdandrea> skraynev_: meaning #openstack-dev ?
20:59:32 <skraynev_> nope
20:59:37 <jdandrea> Oh. :)
20:59:40 <skraynev_> I meant openstack-dev mailing list
20:59:44 <jdandrea> Ahhh, that. Yes.
20:59:52 <jdandrea> "I knew that." *grins*
20:59:54 <jdandrea> Sure.
21:00:16 <skraynev_> #endmeeting