15:00:04 <therve> #startmeeting heat
15:00:05 <openstack> Meeting started Wed Aug 31 15:00:04 2016 UTC and is due to finish in 60 minutes.  The chair is therve. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:09 <openstack> The meeting name has been set to 'heat'
15:00:13 <therve> #topic Roll call
15:00:17 <therve> Hola!
15:00:25 <zaneb> o/
15:00:39 <cwolferh> o/
15:00:50 <ramishra> hi
15:01:02 <spzala> o/
15:01:20 <duvarenkov> hi
15:01:27 <Drago> o/
15:01:54 <therve> Qiming, skraynev ?
15:01:59 <skraynev> o/
15:02:07 <skraynev> therve: thx
15:02:07 <syjulian> o/
15:02:52 <therve> #topic Adding items to agenda
15:02:58 <therve> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282016-08-31_1500_UTC.29
15:03:22 <therve> #topic n3 status
15:03:31 <therve> #link https://etherpad.openstack.org/p/heat-newton-reviews
15:03:40 <therve> #link https://launchpad.net/heat/+milestone/newton-3
15:04:47 <therve> So
15:05:07 <therve> Thanks for the one that cleaned up the bp :)
15:05:24 <therve> I think I'll bump the cinder quota one
15:05:33 <therve> The condition bp is mostly in bug fixing mode
15:05:57 <ramishra> conditions one last patch left to land.
15:06:14 <therve> Cool
15:06:37 <therve> We have a good number of bugs in progress, but I think they can get into rc1?
15:07:16 <therve> Maybe not the oslo.db work, though I would have like it to be there
15:07:16 <skraynev> therve: I don't mind ;)
15:08:17 <therve> Anyone missing with a feature that may need a FFE?
15:08:25 <Qiming> o/
15:08:35 <ramishra> shardy was getting nervous about convergence in tripleo, he does not seem to be around. Should we communicate the plan by a ML thread?
15:08:43 <ricolin> therve: can you share the link of oslo db work?
15:09:05 <therve> ricolin, https://bugs.launchpad.net/bugs/1479723
15:09:05 <openstack> Launchpad bug 1479723 in heat "Replace deprecated EngineFacade from oslo_db" [High,In progress] - Assigned to Steve Baker (steve-stevebaker)
15:09:32 <ricolin> therve: Oh! this one! thx
15:09:55 <therve> ramishra, Yeah that seems like a good idea, I'll do that
15:10:07 <zaneb> ramishra: so do tripleo have convergence enabled in the undercloud?
15:10:16 <therve> #action therve to send email for convergence status
15:10:18 <zaneb> because if they do I think they're nuts
15:10:21 <therve> zaneb, No :)
15:10:33 <zaneb> ok, cool
15:10:39 <zaneb> so why is he nervous then?
15:10:42 <ricolin> lol
15:11:04 <therve> Because he still cares about heat :)
15:11:15 <therve> The use case not covered by his test is pretty important
15:11:20 <zaneb> in the overcloud you mean?
15:11:27 <ramishra> they have a patch to disable it, they have not done any testing with it yet and it would be the default from this release
15:11:30 <therve> In general
15:11:42 <ramishra> for heat
15:12:04 <zaneb> therve: Rabi said he was specifically "nervous about convergence in tripleo" which is why I'm asking
15:12:25 <therve> zaneb, Ah. Yeah I think Rabi's wrong then :)
15:12:41 <zaneb> ok
15:13:18 <zaneb> everybody should be nervous about convergence (or any other massive architecture switchover)
15:13:29 <ramishra> What I meant is, he would like the default in heat to be changed, if we can't fix it before this release.
15:13:44 <therve> Yeah but this is not tripleo related
15:14:06 <zaneb> ramishra: specifically this issue right? https://review.openstack.org/#/c/329460/
15:14:20 <therve> zaneb, Yep
15:14:21 <ramishra> yep, in_progresss delete
15:14:52 <zaneb> ok. I discussed that with therve yesterday. I believe that we are in good shape to get that fixed before RC
15:15:33 <zaneb> I agree with shardy that it's almost a show-stopping bug if it were not
15:15:42 <therve> Right
15:15:59 <therve> I think if by rc1 it's not running, we should switch back to legacy by default
15:16:16 <therve> (ie 2 weeks from now)
15:16:35 <zaneb> I think that's fair
15:16:46 <zaneb> just changed the bug priority High -> Critical
15:16:59 <zaneb> I also think we'll have no problem making it
15:17:10 <therve> Sweet
15:17:39 <skraynev> Wow. So we will not switch back :) it's really good.
15:17:48 <therve> So to conclude the status, I'll cut n3 some time tomorrow morning, push a couple of bugs out of rc1, most into it
15:18:14 <therve> And we'll see if someone as a FFE, maybe cinder quota one
15:18:29 <therve> #topic Stable releases for Mitaka and Liberty
15:18:42 <syjulian> what is ffe?
15:18:52 <therve> syjulian, Feature Freeze Exception
15:19:10 <therve> Do I need to tag some stable releases?
15:19:16 <therve> Who put that in? :)
15:19:17 <zaneb> so, I discovered the other day that we have never done a stable release for Mitaka
15:19:47 <therve> Yeah I guess it doesn't happen automatically
15:19:49 <zaneb> it used to be that there was some sort of schedule where the stable-maint team cut stable releases at scheduled milestones
15:19:57 <zaneb> apparently that isn't a thing any more
15:20:07 <zaneb> so I think we should do one
15:20:19 <skraynev> zaneb: what I need to do to help with it ? :)
15:20:23 <skraynev> if I can help.
15:20:51 <zaneb> it's kinda scary because there are usually a bunch of bugs found right after the release that get wrapped up into an early x.y.1
15:21:21 <therve> I guess I'll tag whatever is on top of both branches
15:21:21 <zaneb> skraynev: so I believe it's just a matter of submitting a review to tag a release
15:21:49 <zaneb> wanted to bring it up here in case anybody has stuff that urgently needs to be included
15:22:45 <therve> #link https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:stable/mitaka
15:22:58 <therve> Nothing major in here that I can see, except invalid stuff
15:23:19 <therve> #link https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:stable/liberty
15:23:35 <therve> Some old stuff
15:24:10 <zaneb> looks like Liberty stuff could use some reviews
15:24:12 <skraynev> therve: I see , that for mitaka all patches have -1 for tests or for review
15:24:31 <skraynev> however for liberty we have two candidates for merge
15:24:38 <skraynev> may be we may merge them right now?
15:24:41 <zaneb> let's get on that today and then therve can tag all 3 branches tomorrow?
15:25:00 <therve> +1
15:25:04 <skraynev> oh. sorry one of them with with two -1
15:25:14 <skraynev> ok, then only one
15:25:22 <therve> #action therve to release liberty and mitaka
15:25:35 <zaneb> cool, and finally: we need a better system for scheduling these
15:25:56 <therve> Yeah, agreed. I was hoping someone would complain when they need it
15:26:05 <skraynev> zaneb: do you mean some external tool with reminders or ?
15:26:17 <therve> Otherwise, cutting them around the master releases sounds like a good reminder?
15:26:20 <skraynev> zaneb: or some fix schedule ?
15:26:21 <zaneb> skraynev: yes, some external forcing function
15:27:02 <skraynev> therve: do you mean milestones ?
15:27:11 <therve> skraynev, Yep
15:27:13 <ramishra> would it be good to do a release/tagging of stable branches(if required) with milestone tagging?
15:27:23 <skraynev> sounds workable.
15:27:34 <skraynev> it's not so often and not so rare
15:27:38 <zaneb> therve: +1 - milestone 1 would be a good time to tag the first stable release from the prev branch
15:27:42 <therve> At least we can think about them at that point, we don't have to release if nothing happened
15:28:28 <ramishra> oh I repeated what therve said;)
15:28:37 <zaneb> ok, I'll add that to the PTL guide wiki page
15:28:47 <therve> Ah thanks, I was wondering where to put that info :)
15:28:51 <shardy> +1 we've ended up doing pretty much that for TripleO
15:29:04 <shardy> otherwise the stable releases get forgotten
15:29:33 <therve> Cool, moving on
15:29:47 <therve> #topic Brain storming for design summit topics
15:29:56 <therve> So yeah we should start that
15:30:03 <skraynev> therve: I added this one as a reminder :)
15:30:25 <therve> #link https://etherpad.openstack.org/p/newton-heat-sessions
15:30:28 <skraynev> We had a request for spaces and need to figure out what we want to discuss
15:30:28 <therve> That was the past one
15:30:58 <therve> So https://etherpad.openstack.org/p/ocata-heat-sessions
15:31:55 <syjulian> so do we just write on the etherpad if we have topics?
15:32:04 <therve> syjulian, Please!
15:32:21 <syjulian> dmiid :)
15:32:25 <shardy> therve: re the convergence questions I missed earlier (sorry), we disabled convergence for TripleO because we tested and it didn't work for us
15:32:26 <skraynev> therve: do we need add our usual about convergence  ? :)
15:32:38 <therve> skraynev, Most likely :)
15:32:38 <shardy> in particular the deleting in-progress nested stacks thing was a totall show-stopper
15:32:52 <shardy> I'll re-test post newton-3 and let you know how it goes ;)
15:33:08 <therve> shardy, Yep. I don't feel that supporting tripleo by the release is critical, but that particular bug is
15:33:26 <shardy> therve: agreed
15:33:27 <therve> shardy, I'll send an email, but the decision is to revert back if it's not fixed by rc1
15:33:45 <zaneb> shardy: but it will be! :)
15:33:49 <shardy> +1
15:34:07 <therve> skraynev, Anything in particular for the brainstorm? We don't have to go too far for now
15:34:14 <therve> But it's nice to start thinking about them
15:34:30 <shardy> therve, zaneb: let me know when you think it's fixed and I'll see if I can break it ;)
15:34:55 <skraynev> therve: unfortunately I have not any ideas right now :(
15:35:18 <therve> That's okay, kicking the ball is good
15:35:29 <therve> #topic Design summit spaces decision
15:35:30 <zaneb> shardy: ack. when your functional test patch passes we'll call it fixed :)
15:35:37 <skraynev> therve: if we have not really much, then we may just request to have 3 fishbowls and 6 work sessions
15:35:51 <shardy> I'd like to see a session on performance improvements, to see where we are with the improvements planned, and what more can be done
15:36:02 <therve> skraynev, Sounds good. I feel we could have done that already last time
15:36:10 <shardy> performance and memory usage
15:36:20 <therve> And as it seems we'll have less space, let's be good citizen
15:36:36 <therve> shardy, +1, it's always a good idea to see what we've done
15:36:54 <ricolin> performance+1
15:38:02 <skraynev> therve: if you talk about real content, that we probably have 1 more month. However if we talk about spaces we need to give answer today/tomorrow to ttx
15:38:25 <skraynev> AFAIK today is deadline for submitting number of sessions
15:38:41 <therve> skraynev, Yeah I know. I don't think anyone has the real content, so I think you suggestion is fine.
15:39:13 <skraynev> also ttx mentioned, that they think to give some delay for decision, but I have not any info about it right now
15:39:16 <zaneb> my only question is if we have enough stuff for 3 fishbowls in what is a short cycle
15:39:38 <zaneb> i.e. should we exchange one of those fishbowls for another work session
15:39:54 <zaneb> (we can always find *something* to talk about in a work session)
15:40:00 <therve> I didn't feel that the difference was really critical TBH
15:40:09 <zaneb> ok
15:40:10 <ramishra> we may ask for the sessions on Wed/Thu, so that we can have the contributer meetup on Friday before noon?
15:40:21 <skraynev> therve: probably it make sense for host.
15:40:27 <therve> We really need to try to not conflict with tripleo this time, though
15:40:33 <shardy> +1
15:40:38 <skraynev> because some other projects can want to have fishbowl
15:40:48 <shardy> I'll try to remember to request scheduliing anti-affinity this time ;)
15:41:06 <therve> :)
15:41:17 <shardy> we've not requested many sessions, so hopefully should be OK
15:41:40 <therve> Cool, moving on
15:41:43 <therve> #topic Support convergence phase 2 for deprecated resources
15:41:45 <zaneb> therve: btw I will not be there on Friday at all, so the more sessions we can get into Wed/Thu the better for me
15:41:56 <skraynev> therve: will you sent info to ttx?
15:42:04 <therve> skraynev, Yep
15:42:10 <skraynev> ok. thank you :)
15:42:25 <therve> zaneb, OK, I think it's scheduled after the request, I'll see
15:42:37 <shardy> Is anyone interested in discussing better support for data transformations?
15:42:44 <zaneb> thanks skraynev for taking the initiative on that btw
15:43:01 <skraynev> zaneb: np ;)
15:43:06 <shardy> we've got a recurring pattern in tripleo where we spin up a nested stack just to do unspeakable things with nested intrinsic functions in the output block
15:43:25 <shardy> I'd be pretty happy to discuss cleaner ways to do those things in the future
15:43:43 <therve> shardy, Wouldn't the Value resource be a good solution for that?
15:43:49 <zaneb> shardy: https://review.openstack.org/#/c/349136/
15:44:04 <skraynev> shardy: honestly will be really cool to have a session for some user's, TripleO requests
15:44:20 <skraynev> and discuss, may be we missed some interesting features ;)
15:44:31 <duvarenkov> So, do we need to implement support of convergence related features for deprecated resources?
15:44:32 <skraynev> interesting for users
15:44:39 <shardy> therve: ah, I'd forgotten about that, thanks!
15:44:44 <shardy> Yes that may help in some cases for sure
15:44:45 <therve> Oh it got merged while I was away, sweet
15:45:15 <therve> cwolferh, If you write doc for heat, bonus points :)
15:45:39 <cwolferh> therve, sure, where?
15:45:39 <therve> So Peter is not here, I suspect he put the topic above
15:45:49 <skraynev> therve: wait a sec
15:46:08 <zaneb> therve: I think he has his hands full with https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:master+topic:rpd-chunked ;)
15:46:19 <skraynev> therve: The question is about some simple decision
15:46:33 <skraynev> should we add support of Convergence Phase2 for deprecated reources ?
15:46:38 <zaneb> skraynev: no
15:46:42 <therve> skraynev, I think in general no
15:46:55 <therve> In this particular case, I think the patch was written before the resource was deprecated
15:46:55 <skraynev> duvarenkov: ^^^
15:47:03 <therve> So it sucks a bit to throw that away
15:47:18 <therve> #link https://review.openstack.org/#/c/313513/
15:47:20 <therve> FWIW
15:47:35 <therve> That said, it's very low priority, which may mean no
15:47:55 <skraynev> therve: ok, then we may just abandon this patch.
15:48:02 <zaneb> it's essentially never going to get tested, so just say no
15:48:11 <therve> Okay :)
15:48:19 <duvarenkov> Good
15:48:24 <skraynev> so that's all for this topic ;)
15:48:26 <therve> #topic Open discussions
15:49:04 <cwolferh> shardy, if you also think https://review.openstack.org/#/c/359605 would be useful to tripleo, maybe worth lobbying for. maybe to late for ffe though
15:50:30 <shardy> cwolferh: thanks, will check it out
15:50:39 <zaneb> cwolferh: tripleo is about to ship too, so it probably won't hurt to let it wait for Ocata
15:51:03 <shardy> yeah, tbh I've pretty much got my hands full battling to get tripleo FFE's in shape atm ;)
15:51:06 * cwolferh nods
15:51:18 <shardy> but it looks interesting, will check it out, thanks! :)
15:51:38 <cwolferh> yep yep :-)
15:52:03 <ramishra> therve: the devstack plugin is fixed (athough with a workaround) and the heat jobs changed to use the plugin. Though we're stuck with removing the devstack tree code, as there are other service plugins that need heat by default
15:52:19 <ramishra> and there is no way to load a plugin from another plugin
15:52:33 <therve> ramishra, Yeah I think I mentioned that in the spec
15:52:48 <therve> We don't want to break everyone, we should deprecate stuff
15:52:50 <ramishra> so we'll probably have to look at it next release
15:52:58 <therve> It's not like it's super expensive to leave it there
15:53:15 <therve> Though it's be nice if other projects using heat used the in tree one
15:53:18 <shardy> cwolferh: FWIW I think there's going to be a bunch of fun corner cases with that
15:53:33 <shardy> cwolferh: because many intrinsic functions return None, then later some value
15:53:38 <shardy> e.g during validation
15:54:28 <ramishra> but I've a patch for the upgrade scripts to use plugin code we should land it I think https://review.openstack.org/#/c/361566
15:54:32 <cwolferh> shardy, ah, good to know. maybe not as clear cut as i thought
15:54:44 <therve> shardy, We should fix that :/
15:54:49 <shardy> cwolferh: I'll try to create a reproducer and comment on the review when I get time
15:55:03 <cwolferh> shardy, thanks!
15:55:12 <shardy> therve: well, in many cases we can't, because the value doesn't exist until runtime
15:55:23 <shardy> but I agree it can probably be handled better
15:55:26 <therve> shardy, Right, we should return NO_VALUE
15:55:45 <therve> We talked about it in Austin actually, and had somewhat a plan, but nobody handled it
15:56:15 <shardy> therve: ack, provided type validation is disabled during validation I guess that would work
15:56:31 <shardy> and that would help with the problem of nested validation not knowing if a value was provided from the parent stack
15:56:51 <zaneb> shardy: so the idea is to return a Placeholder object that knows its eventual type
15:57:07 <shardy> zaneb: cool, well that would definitely be very useful
15:57:38 <sdake> hey guys ;)
15:57:53 <zaneb> here's trouble
15:57:59 <shardy> hey sdake
15:58:08 <sdake> zaneb - we have meeting for kolla in 4 minutes - no trouble :)
15:58:16 <zaneb> whew ;)
15:59:23 <therve> Alright, thanks all!
15:59:25 <therve> #endmeeting