08:00:08 <ramishra> #startmeeting heat
08:00:09 <openstack> Meeting started Wed Aug 10 08:00:08 2016 UTC and is due to finish in 60 minutes.  The chair is ramishra. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:00:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:00:13 <openstack> The meeting name has been set to 'heat'
08:00:19 <ramishra> #topic Roll call
08:01:24 <huangtianhua> hi
08:01:27 <prazumovsky> hi
08:02:56 <ramishra> skraynev, stevebaker around?
08:04:05 <ramishra> hmm.. seems we don't have many in attendance today.
08:05:12 <ramishra> we should finish this quickly:)
08:05:24 <ramishra> #topic Adding items to agenda
08:05:57 <ramishra> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282016-08-10_0800_UTC.29
08:06:23 <svkr> hi all
08:06:41 <ramishra> #topic Gate status
08:07:00 <ramishra> gate was broken 2 days back with neutron issues.
08:07:05 <shardy> o/
08:07:17 * shardy sorry for being late
08:07:21 <ramishra> it seems fine from yesterday, ofcourse with the known failures
08:08:12 <ramishra> shardy hi
08:08:21 <ramishra> #topic N3 status
08:08:31 <ramishra> # link https://launchpad.net/heat/+milestone/newton-3
08:09:44 <ramishra> there are plenty of stuff in the review queue, we should try land the conditions patches.
08:10:23 <shardy> I'm still confused re the status of https://bugs.launchpad.net/heat/+bug/1592374
08:10:23 <openstack> Launchpad bug 1592374 in heat "deleting in_progress stack with nested stacks fails with convergence enabled" [High,Confirmed]
08:10:36 <ramishra> shardy: it's not fixed yet.
08:10:39 <shardy> To me it's a critical, release blocking regression, and it's been unassigned for two months
08:10:58 <ramishra> Last I know, anant was working on a patch on top of zane's series.
08:11:06 <shardy> ramishra: what's the plan if it can't be fixed before release, switch back to non-convergence by default?
08:11:18 <skraynev_> shardyЖ нуы
08:11:20 <ramishra> yeah, without that being fixed we would revert back
08:11:23 <skraynev_> shardy: yes
08:11:41 <skraynev_> sorry - wrong keyboard layout :)
08:11:53 <ramishra> shardy: do you think we can still target https://blueprints.launchpad.net/heat/+spec/environment-merging for n3?
08:11:58 <shardy> Ok, well good to hear it's being worked on, I've got a functional test posted which can be rebased onto the fix when it's ready
08:12:09 <shardy> ramishra: Yes, I'm planning to review it today
08:12:12 <shardy> thanks for working on it
08:12:42 <ramishra> shardy: thanks!
08:13:09 <shardy> https://review.openstack.org/#/c/330414/ the spec for that still needs to land if anyone has a moment to look
08:13:24 <prazumovsky> ramishra: also, could you add some examples to docs after landing env merge?
08:13:47 <ramishra> huangtianhua: I see -1 from zaneb on one of the patches in the condital series.
08:13:49 <shardy> I can help with docs too based on the usage we have planned for TripleO
08:14:12 <ramishra> huangtianhua: conditional series
08:14:28 <ramishra> prazumovsky: yeah I plan to work on the docs after we agree on the approach.
08:14:37 <prazumovsky> thanks!
08:14:39 <huangtianhua> ramishra, yes, he suggested don't to refactor definition validating
08:15:13 <ramishra> shardy: I was thinking of updating the environment-merge spec after I get the feedback from you on the patches
08:15:32 <shardy> ramishra: Ok, sure that's fine - we cam WIP it if that's the plan
08:15:45 <shardy> I just thought we'd want it landed before we start committing the implementation
08:15:55 <ramishra> huangtianhua: so should we leave that refactoring and land the other patches?
08:16:09 <shardy> we could just push any revisions to it as a follow-up patch, I don't really mind :)
08:16:22 <ramishra> shardy: that sounds fine too.
08:16:46 <huangtianhua> you can see the comment of zane, I'm not sure whether we can put the common methods into engine/template.py, so what's your opinions:)
08:16:53 <skraynev_> shardy: RE: spec - merged. sounds good IMO
08:17:06 <shardy> skraynev_: thanks! :)
08:17:41 <skraynev_> shardy: np ;)
08:18:19 <ramishra> huangtianhua: I would be ok if we can leave the refactoring for later
08:18:30 <ramishra> shardy: opinion on https://review.openstack.org/#/c/345946/
08:18:34 <ramishra> skraynev: ^^
08:20:55 <ramishra> should I move on to the next topic?
08:21:02 <ramishra> #topic devstack plugin
08:21:14 <ramishra> I've added this one.
08:21:19 <shardy> ramishra: FWIW I agree with zaneb, perhaps there's some other way the refactor can be done without modifying the base-class
08:21:28 <shardy> e.g a mixin or a utilty module
08:21:46 <ramishra> shardy: yeah
08:22:03 <huangtianhua> shardy, ok, will to do it in a utilty module
08:22:21 <shardy> huangtianhua: Thanks - sorry for the extra work
08:22:43 <huangtianhua> shardy, :)
08:22:45 <ramishra> ok, on the devstack plugin thing, it's broken or does not work as of yet
08:23:07 <ramishra> I mean the in-tree stuff that we had added sometime back
08:23:29 <ramishra> I've put a workaround for it https://review.openstack.org/#/c/352329/
08:24:10 <ramishra> so basically plugin and the stuff in stack.sh both duplicate the heat stuff.
08:25:02 <ramishra> we can land this woraroudn and then move to the plugin
08:25:39 <ramishra> project-config patch https://review.openstack.org/#/c/317817/
08:27:31 <ramishra> and once we clean up stack.sh https://review.openstack.org/#/c/317618/ we can revert this workaround.
08:27:35 <ramishra> any thoughts?
08:28:02 <ramishra> not sure if there is a better approach though.
08:29:12 <ramishra> we would like to fix this before the release
08:29:38 <ramishra> shardy, skraynev wdyt?
08:30:03 <prazumovsky> You suggest to merge workaround, which allows to work plugin correctly, wait until clean up not merged, after it revert workaround? Or I miss something?
08:30:35 <ramishra> prazumovsky: we will move to use the plugin at the gate after the plugin works.
08:30:51 <ramishra> that's one step missing in your description
08:31:17 <prazumovsky> Oh, sorry, now it's more clearer
08:32:55 <ramishra> ok, we can discuss(other ideas, concerns) on the patch.
08:33:03 <prazumovsky> Your suggestion allows to start using plugin faster than wait until clean up on project withiut cores will be merged, so imo +1
08:33:26 <prazumovsky> will review workaround
08:33:54 <ramishra> prazumovsky: I don't see any other way to make it work as we can't cleanup devstack code without the plugin working.
08:34:17 <ramishra> #topic Open discussion
08:34:40 <prazumovsky> ramishra: got it
08:35:19 <shardy> ramishra: +1 the workaround seems fine if it's a way to move forward
08:35:51 <ramishra> shardy: thanks!
08:36:02 <ramishra> anything else we want to discuss?
08:36:11 <shardy> http://docs.openstack.org/developer/heat/template_guide/hot_spec.html#parameter-groups-section
08:36:14 <shardy> I have one thing
08:36:25 <shardy> currently, a parameter can only be a member of zero or one parameter groups
08:36:40 <shardy> IIRC this is something we did to align with CFN very early in heat development
08:36:54 <shardy> I would like to change this for HOT, so that a parameter can be a member of multiple groups
08:36:59 <shardy> any thoughts on that?
08:37:06 <skraynev_> nope from my side ;)
08:37:08 <prazumovsky> and another one (type slowly, from phone) Can someone explain.me, why rsrc defn validation allows to use Function type properties, if in fact it's not work and raises different errors.
08:37:12 <ramishra> +1
08:37:27 <prazumovsky> +1
08:37:29 <huangtianhua> +1
08:37:34 <KanagarajM> +1
08:37:50 <shardy> Ok, sounds good, thanks, I'll see if I can get a patch posted today :)
08:38:05 <prazumovsky> will follow
08:38:46 <shardy> prazumovsky: properties can be resolved at runtime, so that even if a validation step fails (e.g the Function resolves to None because it references something that doesn't yet exist), at runtime it will work
08:39:13 <shardy> It's one of those areas where static vs runtime validation gets a bit tricky
08:40:17 <ramishra> I thought we had plans to improve validation this cycle as discussed during the last design summit.
08:40:26 <shardy> jtomasek: ^^ FYI this may help with TripleO parameter categorization
08:40:49 <prazumovsky> i.e. if properties equals to json type parameter - ift fails in case of code. Do I need to add some template validation that restricts using functions to sections? Or just leave it for later?
08:41:23 * jtomasek reads back
08:42:19 <jtomasek> shardy: +1
08:43:08 <ramishra> ok, should we move back to #heat then?
08:43:38 <shardy> prazumovsky: if you can provide some more examples I'm happy to discuss futher, hard to discuss clearly without examples :)
08:43:55 <shardy> ramishra: +1, thanks!
08:44:00 <prazumovsky> shardy: ok, will provide
08:44:06 <prazumovsky> let's move
08:44:27 <ramishra> #endmeeting