20:01:06 <zaneb> #startmeeting heat
20:01:06 <mattoliverau> thanks notmyname
20:01:06 <openstack> Meeting started Wed Aug 13 20:01:06 2014 UTC and is due to finish in 60 minutes.  The chair is zaneb. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:09 <openstack> The meeting name has been set to 'heat'
20:01:23 <zaneb> #topic roll call
20:01:26 * jpeeler is here
20:01:28 <pas-ha> o/
20:01:30 <shardy> o/
20:01:33 <ryansb> o/
20:01:59 <spzala> Hi
20:02:01 <jasond`> o/
20:02:03 <zaneb> stevebaker?
20:02:18 <skraynev> o/
20:02:20 <tspatzier> hi
20:02:50 <randallburt> hello
20:03:21 <zaneb> ok, let's get into it
20:03:31 <zaneb> #topic Review action items from last meeting
20:03:48 <zaneb> zaneb check with stevebaker about progress on gap coverage plan
20:04:00 <zaneb> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Heat_Gap_Coverage#Improved_functional_testing
20:04:07 <zaneb> the plan is up
20:04:10 <stevebaker> Done
20:04:13 <zaneb> we just have to execute
20:04:28 <zaneb> #topic Adding items to the agenda
20:04:39 <zaneb> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282014-08-13_2000_UTC.29
20:04:51 <zaneb> any other topics?
20:05:08 <stevebaker> Reviews on the functional test changes please
20:05:29 <stevebaker> I do, just getting a keyboard
20:06:10 * shardy wonders how stevebaker is typing without a keyboard ;)
20:06:13 <stevebaker> right
20:06:18 <stevebaker> (phone)
20:06:32 <stevebaker> agenda item: icehouse issues
20:06:32 <shardy> ah
20:06:37 <tspatzier> siri?
20:06:53 <skraynev> looks very fast...
20:07:04 <zaneb> ok
20:07:27 <zaneb> #topic Mid-cycle meet-up
20:07:41 <zaneb> Reminder: this is next Mon-Wed
20:08:17 <zaneb> #action zaneb to email out details of when/where to meet up
20:08:17 <stevebaker> tripleo had a good format, spread the formal topics over the mornings, then hackfest for the rest of the time
20:08:17 <skraynev> zaneb: so the next meeting will be skipped?
20:08:18 <shardy> Do we need to revisit the discussion re stevedore for resource plugins, or has the decision been made now?
20:08:45 <shardy> I see asalkelkd still has a patch up and IIRC it was somewhat in-flux before I went on PTO
20:09:08 <zaneb> skraynev: that's probably a good idea... it will be 8am there
20:09:14 <randallburt> shardy:  I was going to start looking at those next once the client plugin stuff finally landed
20:09:42 <zaneb> #info next week's Heat IRC meeting is cancelled
20:09:54 <shardy> randallburt: Ok thanks for the info
20:10:11 <skraynev> zaneb: thx
20:10:25 <zaneb> so, spoiler alert: it will be 9am in the lobby of Red Hat Tower on Monday
20:10:43 <zaneb> #topic Feature Proposal Freeze
20:11:12 <zaneb> next Thursday is the Feature Proposal Freeze deadline
20:11:18 <skraynev> randallburt: I will try to not block merging of client-plugin patches :)
20:11:33 <randallburt> lol, thanks skraynev ;)
20:11:38 <zaneb> that means that if you want to introduce new features in Juno, there must be patches up for review by then
20:11:42 <mspreitz> zaneb: FPF is deadline for approval?
20:11:50 <mspreitz> oh, got it
20:11:51 <zaneb> mspreitz: no
20:11:54 <stevebaker> zaneb: by when?
20:12:01 <stevebaker> oh, next thursday
20:12:03 <zaneb> stevebaker: next Thursday
20:12:04 <skraynev> randallburt: so for questions only +1 :)
20:12:16 <randallburt> skraynev:  sounds good
20:12:28 <zaneb> this has been your public service announcement
20:12:37 <zaneb> #topic Update replace with dependencies
20:12:41 <zaneb> I don't know who added this
20:12:49 <mspreitz> what does it mean?
20:12:54 <pas-ha> skraynev
20:12:55 <zaneb> ah, skraynev
20:12:56 <skraynev> it is mine
20:13:01 <skraynev> yes.
20:13:13 <skraynev> it's more similar on one question about bug
20:13:30 <skraynev> https://bugs.launchpad.net/heat/+bug/1356084
20:13:32 <uvirtbot> Launchpad bug 1356084 in heat "Cannot delete the stack after replacing image during stack-update" [Undecided,New]
20:13:58 <skraynev> IMO, it's not duplicated, the real problem in resource port and our update replace
20:14:04 <zaneb> so I think that's the same bug as https://bugs.launchpad.net/heat/+bug/1334514
20:14:06 <uvirtbot> Launchpad bug 1334514 in heat "cannot delete the stack after heat-engine down in middle of stack-update" [Medium,Fix committed]
20:14:08 <zaneb> (which is fixed)
20:14:27 <pas-ha> UpdateReplace behavior when the replaced resource has dependencies that allow for only 1 "dependent"
20:14:33 <skraynev> Yes, I saw your comment..
20:14:39 <pas-ha> like port on Server
20:15:15 <skraynev> during replace we create second server and try to use old port
20:15:32 <skraynev> but according to neutron model it's not possible
20:15:45 <stevebaker> nova/neutron port interaction is a mess right now
20:15:49 <zaneb> ah yes, I see your point
20:15:50 <skraynev> to have two servers with same port
20:16:10 <shardy> skraynev: should you be using the rebuild image update policy?
20:16:17 <stevebaker> we should be able to detach the port from the old server at some point in the update process
20:16:25 <shardy> instead of replacing the server?
20:16:38 <pas-ha> I think it is more than port, I presume the same would go for volume attached (can not attach to two servers at once)
20:16:41 <skraynev> stevebaker: +1 for this idea
20:16:42 <mspreitz> stevebaker: but timing is wrong, update makes new before deleting old, right?
20:16:50 <zaneb> didn't we do something like this already for another type of resource?
20:17:04 <zaneb> pas-ha: I suspect that's why VolumeAttachment exists
20:17:19 <pas-ha> true
20:17:31 <stevebaker> mspreitz: the port would have to be attached to the new post-create
20:17:31 <zaneb> maybe we need a PortAttachment :(
20:17:40 <stevebaker> gah
20:18:14 <skraynev> shardy: hm... I don't think about this case, but as I understand it's different solution which can not help with current bug
20:18:24 <stevebaker> or we deprecate the port resource and make it possible to specify all port details in the server networks list
20:18:25 <zaneb> please nobody implement PortAttachment
20:18:38 <shardy> skraynev: I'm just suggesting it might be a workaround
20:18:59 <zaneb> stevebaker: that might also eliminate the opposite problem we also have, of Nova deleting the port from under us
20:19:11 <mspreitz> yes, +1 on stevebaker's suggestion
20:19:23 <pas-ha> stevebaker, detaching port from old during update has potential to have a old instance without ports if rollack happens
20:19:32 <pas-ha> s/rollack/rollback
20:19:42 <stevebaker> zaneb: it gets better, currently nova *doesn't* always delete ports that it creates, resulting in undeletable stacks!
20:19:53 <skraynev> shardy: may be. I think about some hacking of update replace process.
20:20:09 <zaneb> stevebaker: what, do they just roll some dice???
20:20:21 <stevebaker> I was going to suggest a summit session on a rich server networks property
20:20:28 <pas-ha> may be smth like post/pre-replace
20:20:36 <skraynev> zaneb: it's destiny ... :)
20:20:50 <zaneb> I'd like to have a summit session on a sensible API for neutron
20:21:06 <stevebaker> zaneb: and now they're talking manging port lifecycle in novaclient ;)
20:21:42 <stevebaker> managing
20:21:50 <zaneb> when it's easier to store state in the client(s) than your server, you know you've taken a wrong turn
20:22:29 <skraynev> pas-ha: do you mean this https://review.openstack.org/#/c/89363/19 ?
20:22:32 <stevebaker> anyhoo, arosen has a change to fix the port deleting which is still in review
20:22:36 <zaneb> because nobody ever uses clients on different machines...
20:23:12 <pas-ha> skraynev, not really, more of resource (not stack) plugpoints
20:23:36 <pas-ha> and not really plugs, just another function of the Resource class
20:24:02 <skraynev> pas-ha: only for port resource?
20:24:02 <pas-ha> which if implemented makes what's needed during update-replace
20:24:24 <zaneb> #action skraynev document mob wisdom on bug 1356084 in launchpad
20:24:25 <uvirtbot> Launchpad bug 1356084 in heat "Cannot delete the stack after replacing image during stack-update" [Undecided,New] https://launchpad.net/bugs/1356084
20:24:30 <zaneb> moving along....
20:24:36 <pas-ha> well, if it is only port that misbehaves, than I'd vote for stevebaker proposition
20:24:48 <zaneb> #topic icehouse issues
20:24:59 <zaneb> stevebaker: we have icehouse issues?
20:25:20 <stevebaker> I don't have the link, but search for "heat rstrip" on ask.openstack.org
20:25:35 <zaneb> aha, I know it well
20:25:41 <stevebaker> there seems to be many people getting this
20:26:16 <zaneb> does anyone remember which patch fixed it in Juno?
20:27:02 <zaneb> #link https://ask.openstack.org/en/question/44120/heat-and-image-nontype-object-has-no-attribute-rstrip/
20:27:09 <zaneb> #link https://ask.openstack.org/en/question/22518/failed-to-create-stack-got-error-nonetype-object-has-no-attribute-rstrip/
20:28:55 <zaneb> I'll take that as a no
20:29:34 <zaneb> #action stevebaker raise a launchpad bug for rstrip(None) issue from ask.openstack
20:29:49 <shardy> Looks a lot like https://answers.launchpad.net/heat/+question/232632
20:29:49 <zaneb> since apparently none of the people asking are going to do it
20:30:02 <stevebaker> the other issue is that the install guides (and installers like packstack) are not setting up the stack domain, and lots of people are having auth issues, which I assume is just them not using an admin user
20:30:04 <shardy> It's not folks upgrading and using havana config files is it?
20:30:24 <shardy> stevebaker: recent packstack does create it
20:30:33 <stevebaker> oh, good
20:30:34 <zaneb> ooh, could be
20:30:52 <shardy> stevebaker: I can take an action to contribute docs, after FPF
20:31:08 <shardy> I blog-documented it, but need to refactor into official docs
20:31:49 <stevebaker> shardy: there is a docs bug to do that.
20:34:07 <zaneb> #topic Critical issues sync
20:34:14 <zaneb> we have one open at the moment
20:34:31 <zaneb> #link https://bugs.launchpad.net/heat/+bug/1356097
20:34:33 <uvirtbot> Launchpad bug 1356097 in heat "stack-update from a non-HOT stack to a HOT stack fails" [High,In progress]
20:34:54 <zaneb> I approved stevebaker's fix
20:35:00 <zaneb> #link https://review.openstack.org/#/c/113739/
20:35:10 <zaneb> not sure what will happen if he doesn't remove W-I-P
20:35:21 <stevebaker> I can do that
20:35:45 <skraynev> we can wait and will see result :)
20:36:18 <zaneb> it definitely isn't in the gate atm
20:36:38 <stevebaker> I have approved myself
20:36:55 <zaneb> w00t
20:37:02 <zaneb> Starting gate jobs.
20:37:10 <zaneb> sorted.
20:37:31 <zaneb> lifeless: ^ FYI
20:38:02 <zaneb> anything else critical?
20:38:11 <zaneb> we've discussed a couple already
20:39:04 <stevebaker> could we quickly talk about the review queue?
20:39:13 <zaneb> it sounds like https://bugs.launchpad.net/heat/+bug/1354962 is fixed at least
20:39:14 <uvirtbot> Launchpad bug 1354962 in heat "stack-update adding a parameter leads to heat stack-list breaking" [Undecided,Fix committed]
20:39:35 <zaneb> ok yes, let's talk about the review queue
20:39:44 <stevebaker> its big.
20:39:47 <stevebaker> next topic!
20:39:59 * zaneb peeks at review queue
20:40:12 <randallburt> review the last few client plugin patches please?
20:40:17 <randallburt> we're almost there.
20:40:17 <stevebaker> I wonder if we should have a curated list of priority reviews, like swift does
20:40:32 <zaneb> it's big all right
20:40:57 <ryansb> +1 for priority review queue
20:41:12 <pas-ha> how is this one sorted? http://status.openstack.org/reviews/#heat
20:41:26 <stevebaker> because as a core its hard to know where my reviewing effort is best applied
20:42:02 <skraynev> agree about priority
20:42:10 <zaneb> it's my impression that the stuff that would go in a priority review queue is actually being reviewed
20:42:26 <stevebaker> pas-ha: that is things which are ready for review attention, but it makes no distinction between priority, bugs, features, strategic vs tactical
20:42:40 <zaneb> and the backlog is of stuff that is not going to be regarded by core as priority
20:42:49 <zaneb> mostly because it comes from people outside core
20:43:06 <zaneb> I'm not holding this up as an example of the system working, btw
20:43:24 <zaneb> just as a reason that a priority queue might not improved it
20:43:27 <randallburt> probably more the opposite
20:43:30 <lifeless> zaneb: wicked thanks
20:43:40 <shardy> zaneb: I agree, I think most of us are vaguely aware of the priorities for the looming milestone and review accordingly, but it's the remaining stuff which can fall through the cracks
20:43:52 <zaneb> I'd be interested in hearing different opinions though
20:43:56 <stevebaker> zaneb: I think I'm suggesting we add to your busylist as the owner of the curated list
20:44:02 <shardy> which a priority list will probably make worse
20:44:05 <zaneb> I know stevebaker is keen to get his client patches merged soon ;)
20:44:24 <randallburt> I look at them more as "ours" at this point ;)
20:44:25 <zaneb> stevebaker: -2
20:44:30 <shardy> that said, with finite time before the release, perhaps we should priotitize between now and FF
20:44:31 <randallburt> joint custody
20:44:35 <stevebaker> zaneb: if so, I would be volunteering to curate ;)
20:44:56 <randallburt> maybe something to discuss more at the mid-summit?
20:45:48 <zaneb> stevebaker: but it's the low-priority stuff I am most worried about
20:45:58 <zaneb> we are not being very friendly to new contributors
20:46:17 <zaneb> or, more accurately, to the majority of our non-core contributors
20:46:17 <stevebaker> randallburt: good idea. Long term I'd like a purely technical solution to prioritising review order
20:46:38 <randallburt> stevebaker:  very agreed
20:46:41 <stevebaker> zaneb: having a list doesn't preclude other things being reviewed
20:47:04 <zaneb> btw if people want me to review stuff, add me to the review in Gerrit
20:47:25 <mspreitz> zaneb: I have been assuming that would be rude..
20:47:27 <pas-ha> zaneb, be careful with that :)
20:47:31 <mspreitz> assuming everyone is busy already
20:48:01 <zaneb> so, ideally you know who in core is an expert in the area of the code you're changing
20:48:02 <stevebaker> I need to go soon
20:48:09 <zaneb> and you add them to the review
20:48:14 <randallburt> not rude at all. its gotten to the point where I have people emailing me directly asking for reviews. bad sign if you ask me.
20:48:16 <shardy> mspreitz: actually, provided you do it in a targeted way, it's appreciated, as it makes finding reviews relevant to you easier
20:48:28 <zaneb> I don't think it's rude, because I can easily remove myself again :)
20:48:36 <mspreitz> zaneb: great
20:48:52 <mspreitz> I will try to do some of that judiciously
20:49:00 <stevebaker> I won't tell you all about the secret feature to add all heat-core ;)
20:49:07 <zaneb> for new contributors, it may be hard to know who the expert is in a particular area
20:49:25 <shardy> stevebaker: sssh! ;)
20:49:25 <zaneb> I would rather people ask on IRC who the experts are than to ask on IRC for reviews
20:49:40 <zaneb> stevebaker: no, don't tell us about that
20:49:44 <mspreitz> good clues here, thanks
20:49:45 <randallburt> zaneb:  +1 to that.
20:50:12 <randallburt> gotta run a little early. later, heaters.
20:50:22 <zaneb> pinging for reviews interrupts people and it only a one-off
20:50:32 <zaneb> adding folks in Gerrit is sticky
20:50:53 <shardy> zaneb: +1, particularly if, as some folks are doing, it's pinging multiple times a day :(
20:50:56 <mspreitz> So I have one other topic for opens
20:51:12 <zaneb> shardy: yes, we want to discourage that
20:51:28 * zaneb has been known to ignore reviews from folks who ping/email too much
20:51:38 <zaneb> btw any email is too much
20:52:21 <zaneb> #info if you need reviews, add the core team members who are experts in the domain of the patch to the review in Gerrit
20:53:05 <zaneb> #info if you don't know who the experts are, ask on IRC - that's better than asking for reviews on IRC
20:53:15 <zaneb> #topic Open Discussion
20:53:25 <zaneb> mspreitz: you had something
20:53:42 <mspreitz> Simple, really: does anybody have any template that uses Neutron LBaaS, and works?
20:53:44 <skraynev> zaneb: what about old review, where all experts were added ? will be enough to rebase this change?
20:53:54 <pas-ha> I had one for havana
20:54:04 <zaneb> skraynev: that generates a notification, so usually yes
20:54:11 <mspreitz> pas-ha: pls share
20:54:22 <mspreitz> or do you know it's broken now?
20:54:28 <pas-ha> https://github.com/pshchelo/stackdev/tree/master/templates/demo
20:54:52 <pas-ha> look there, I was doing demo HEat vs Murano and was asked for some templates
20:55:54 <pas-ha> this one https://github.com/pshchelo/stackdev/blob/master/templates/demo/demo-neutronlb.yaml was working during Icehouse cycle, not havana
20:56:04 <mspreitz> pas-ha: will try, thanks
20:56:09 <skraynev> mspreitz: I had one more form this review https://review.openstack.org/#/c/60078/10/tempest/scenario/orchestration/test_loadbalancer.yaml
20:57:13 <ryansb> (beep, 4 minute warning)
20:57:24 <mspreitz> skraynev: what uses TestFIP?
20:58:29 <skraynev> mspreitz: it was used for test
20:58:46 <pas-ha> mspreitz, ping me if smth not clear
20:58:50 <mspreitz> my question is: I do not see it attached to anything
20:59:00 <mspreitz> pas-ha's example has an attachment
20:59:16 <skraynev> mspreitz: to send request to lbaas from external network
20:59:17 <zaneb> ok, let's jump back to #heat
20:59:29 <mspreitz> I will follow up directly, thanks
20:59:32 <zaneb> #endmeeting