07:01:31 #startmeeting heat 07:01:31 Meeting started Wed Mar 30 07:01:31 2016 UTC and is due to finish in 60 minutes. The chair is skraynev. Information about MeetBot at http://wiki.debian.org/MeetBot. 07:01:31 Hello? 07:01:32 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 07:01:34 The meeting name has been set to 'heat' 07:01:44 #topic rollcall 07:01:57 #chairs therve 07:02:31 hi again 07:02:45 \i 07:02:47 #help 07:02:50 \o 07:02:54 hi 07:02:58 o/ 07:03:01 * stevebaker inflates head 07:03:19 stevebaker: could you remind me how to add someone else to chair ? 07:03:22 o/ 07:03:24 O/ 07:03:37 ummm 07:03:55 hash chair? 07:04:21 #chair and #unchair 07:04:22 #chair therve 07:04:22 Warning: Nick not in channel: therve 07:04:23 Current chairs: skraynev therve 07:04:43 might be a bit early for therve 07:05:10 stevebaker: yeah. thx. I wrongly used plural instead of single "chair" 07:05:41 hi 07:06:10 stevebaker: may be. I hope, that he will join if be there . 07:06:23 #topic Adding items to agenda 07:06:41 #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282016-03-30_0700_UTC.29 07:07:00 ramishra: I suppose, that we may add RBAC related question 07:07:08 sure 07:07:30 oh, again 07:08:17 ramishra: done. 07:08:28 o/ 07:08:38 ochuprykov: yeah. however, todays it's a TripleO ;) 07:09:01 morning all, sorry I'm late 07:09:03 something else for agenda ? 07:09:11 shardy: hi. np. ^ 07:09:27 ps: https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282016-03-30_0700_UTC.29 07:09:31 shardy: ^ 07:09:32 sergey, could you add me patch about addind yaql& 07:09:39 my* 07:09:57 https://review.openstack.org/#/c/196984/ 07:10:31 Does someone have a link to the bug/patch re the RBAC issue please? 07:10:51 shardy: I've a revert 07:10:53 ochuprykov: done 07:11:00 ramishra: was it the broken delete thing? 07:11:08 https://review.openstack.org/#/c/299112/ 07:11:08 ramishra: i don't see any info 07:11:18 shardy: yes 07:11:28 you just tell thet something wrong 07:11:32 ramishra: ack, thanks! 07:11:39 shardy: ramishra: could you please wait a bit before related topic ? ;) 07:11:46 https://bugs.launchpad.net/tripleo/+bug/1561172 07:11:46 Launchpad bug 1561172 in tripleo "Overcloud delete never completes" [Critical,Triaged] 07:12:04 skraynev: sure, my question was because there's no link in the agenda ;) 07:12:30 shardy: yeah. I wanted to ask ramishara to share it later ;) 07:12:33 I thought I added it 07:12:50 #topic RC2 status 07:13:33 short update. rc-2 was released yesterday: http://releases.openstack.org/mitaka/index.html 07:14:09 so if we have some critical patches, which may land before next week, we need to release rc3 07:14:21 also new version for python-heatclient was relased 07:14:28 #link http://releases.openstack.org/mitaka/index.html 07:14:32 on the same page 07:14:36 it's 1.1.0 07:15:00 skraynev: that probably should have been 1.0.1, but too late now 07:15:08 I proposed it as 1.0.1, but due to update cliff in requirements it was changed to 1.1.0 07:15:24 stevebaker: initially it was 07:15:31 ah, makes sense 07:16:03 I'll rejig the milestones in launchpad at some point 07:17:05 stevebaker: how exactly ? 07:17:36 stevebaker: by adding rc3 ? 07:17:44 for heatclient 07:18:08 renaming the milestones in the series https://launchpad.net/python-heatclient 07:18:24 ok. doh. I am sorry. I forhot about it. 07:18:29 *forgot 07:19:03 stevebaker: out of interest, is there a script which applies the series/milestones for projects, or do you do it manually? 07:19:15 so tha' all about this topic. got to the next 07:19:25 #topic RBAC patch breaks TripleO 07:19:34 its manual, and I'm not even sure we should keep using launchpad to track this 07:19:35 #link https://bugs.launchpad.net/tripleo/+bug/1561172 07:19:35 Launchpad bug 1561172 in tripleo "Overcloud delete never completes" [Critical,Triaged] 07:19:39 #link https://review.openstack.org/#/c/299112/ 07:20:00 shardy: I suppose - manually 07:20:32 it seems that stack preview still broken 07:20:35 It seems to me due to the RBAC patch, we can revert it or fix it 07:20:43 I've the revert up 07:20:52 shardy: but.. AFAIK some of milestone (n1, n2, n3) were created by ttx. So I believe, that he did it with some script ;) 07:20:52 I think we should quick revert, then figure out functional test coverage which mimics the TripleO (and Magnum) failures before landing anything again 07:20:53 and tested tripleo-ci with depends-on 07:21:16 and it seems to work, I did not see any similar error 07:21:17 shardy: agreed 07:21:28 ramishra: tripleo-ci won't show this issue, we don't currently test deletes 07:21:47 but it is very strange that it breaks delete 07:22:05 shardy: It can with this patch https://review.openstack.org/#/c/297328/, I think 07:22:19 shardy: ochuprykov: khm... guys.. I agree to revert, but.. please keep in mind, that this was merged in mitaka, so we need fix for mitaka, because backport patch with revert, sounds awful 07:22:29 ramishra: aha, yup! Thanks :) 07:22:45 skraynev: yes -- using milestones-create from release-tools 07:22:53 skraynev: backporting a revert is better than a release with a critical regression? 07:23:13 I'm fine with fixing it, but if we can't do that very very fast, we should revert 07:23:21 ttx: got it. thank you :) 07:23:27 ttx: thanks! 07:23:36 shardy: i think it is better to revert 07:23:44 shardy: +1 07:23:53 I'll probably update the dates for n1 to n3 once the schedule is official 07:24:06 let's try to fix it during these two days. 07:24:07 I think it can fixed by adding DELETE in this check https://github.com/openstack/heat/blob/master/heat/engine/resources/template_resource.py#L138, but the reporter says there are more issues with UPDATE etc, so wa 07:24:20 ttx: context of my question is I need to setup series/milestones for TripleO, but that's OT for this meeting :) 07:24:22 shardy: +1 07:24:28 so I wanted we fix the issue properly 07:24:57 if there is no result, we may revert it at Friday.. I suppose, that we may release rc3 before the next Wednesday 07:24:59 ttx: ^ 07:25:26 skraynev: in theory the last RCs are this week 07:25:50 the release team may do further RCs to solve other issues, like source tarball corruption 07:25:50 skraynev: we should land the revert today, not wait until Friday 07:26:05 I agree 07:26:06 ttx: heh... 07:26:08 then any subsequent fix can be considered without the pressure of having broken everything for some users 07:26:10 that is what next week is for -- exceptional RCs, not "normal" ones :) 07:26:30 ttx: ok. 07:26:39 ttx: The issue at hand is a critical regression unfortunately 07:26:50 the only question is fix or revert at this point 07:27:54 I think to fix in proper way, will cost more then a week 07:28:09 shardy: sigh .. 07:28:20 shardy: I decided - revert 07:28:31 shardy: I think revert is better, as we don't know if there can be any further issues. can we not just merge the revert in mitaka, sorry about my ignorance of the release process. 07:28:55 skraynev: OK thanks, I was confused by "we may revert it at Friday" 07:29:19 I have a short business trip for next two days, so ... it will be problematically to release rc3 from train or airplane 07:29:28 ramishra: Yeah I'd propose revert for both branches, then fix and consider backporting the fix for a later stable release 07:29:40 shardy: initially I wanted to revert it at Friday.. 07:30:03 but I wrongly supposed, that rc3 is ok for next week 07:30:23 in the light of last info. I tend to agree with revert 07:31:38 ochuprykov: shardy: However, I suggest to work on next attempt from now. this bug is really painful, so I'd like to close it ;) 07:32:08 ok 07:32:17 i will see what can be done 07:32:51 #topic Yaql support 07:33:01 #ochuprykov; it's yours 07:33:10 yep 07:33:12 could you please share a link ? 07:33:34 https://review.openstack.org/#/c/196984/ 07:33:37 ^^ 07:33:51 the first patch was uploaded a quite ago 07:34:34 i will be very appreciated if somebody looks at it 07:35:33 ochuprykov: some examples showing real problems being solved in templates, and documentation would be useful 07:36:01 Is there any spec for it? 07:36:07 no 07:36:14 blueprint only 07:36:18 I think a spec with examples would be helpful 07:36:30 i will try to addd some useful examples 07:36:37 shardy: ok 07:36:46 will upload a spec 07:36:51 Don't know how it works, some docs or links would be helpful. 07:37:07 link in commit message 07:38:00 http://yaql.readthedocs.org/en/latest/usage.html 07:38:03 I'm generally positive on having one, people who don't like the syntax of yaql can ignore it - as long as it does the arbitrary x->y transforms users sometimes need in templates 07:38:08 There also appears to be overlap wrt path bases parameters to work out, based on yaql_example.yaml 07:38:13 again a spec will help there 07:38:20 e.g is 07:38:40 https://review.openstack.org/#/c/196984/4/yaql_example.yaml 07:38:58 line 16 there the same as get_param: [a_list, 0] ? 07:39:25 Or [a_list, 1] rather 07:39:29 * shardy needs coffee ;) 07:39:41 second 07:40:02 it's kinda weird to have parameters evaluate without any get_param is my point 07:40:31 We can work this out in the spec, but examples including nested parameters/attributes would be good 07:40:46 we can access the parameters from yaql expression 07:41:05 $parameters 07:41:24 shardy, Agreed, I didn't see anything useful from the examples 07:41:27 Ok, so $parameters basically shadows get_param 07:41:29 it seems more convinient than using get)param 07:41:35 at the least that's a documentation challenge ;) 07:41:36 IE, what can you do that you can't with other things? 07:41:44 ochuprykov: I think, that the best way, (as was mentioned above) using spec for clarification all details of implementation 07:41:51 do not shadow, just add a possibility to use them from yql 07:42:04 ochuprykov: having multiple ways to do one thing is likely to confuse users 07:42:22 e.g in the "c" example you then nest get_attr, but you don't use get_param above 07:43:07 Anyway, overall it looks quite interesting, I'd like to discuss further on the spec :) 07:43:18 shardy: ok 07:43:22 You shouldn't highlights new things that were not possible before, not things done slightly differently just because 07:44:06 It also seems we'll overlap with the conditionals that tiantian has been working on 07:44:16 * therve nods 07:44:22 http://yaql.readthedocs.org/en/latest/readme.html 07:45:26 overlap is only in possible merge conflicts) 07:45:53 ochuprykov, overlap as it does some of the same things 07:46:10 what things? 07:46:14 Though we still need the resource level condition attribute 07:46:26 Like equals 07:46:50 yaql is evaluate arbitrary expression, so yes, it can evaluate booleans 07:47:53 but conditionals is seems to me like different feature for different purposes 07:48:24 probably it would be good to have a spec and have a session to discuss the spec at the summit? 07:48:40 will be good 07:49:05 it can brings really a lot of possibilities 07:49:18 Have a discussion at the summit would be good. 07:49:31 ochuprykov, Can you do basic arithmetic? 07:49:49 ochuprykov: that's actually one of the problems - if you add something like this which is really unconstrained and arguably complex, it's possible not all providers will want to enable it 07:50:05 e.g start fielding effectively programming questions from their users via support tickets 07:50:20 shardy: it is bounded in some ways 07:50:34 for example in using memory 07:50:41 LOL 07:50:48 We should discuss at least with those running Heat in public cloud environments, because we don't want to damage portability of HOT templates 07:50:52 some *bad* things are prohibited 07:51:05 ochuprykov: well that is good to hear :D 07:51:28 therve: what do you mean? 07:51:44 ochuprykov, Can you do param + 1? 07:51:50 yeah 07:52:03 arbitrary arithmetic expression 07:52:07 That would solve that annoying index bug that was opened recently, where the solution looked awful to me 07:52:14 at leats +-* 07:52:56 therve: I thought you were asking ochuprykov about math skills o_O 07:53:09 Heh heh 07:53:17 :D 07:53:22 ) 07:53:34 stevebaker, "As a PTL, I will now personally check every core skills" 07:53:47 2+2=4 07:54:09 Moving on? 07:54:14 yeah 07:54:17 #topic Open discussion 07:55:14 FWIW I'll propose alternate meeting times, so that I can at least for sure attend one 07:55:39 therve: do you plan to send any mail about it? 07:55:54 skraynev, Yes that will be the proposal :) 07:56:51 therve: great :) thx 07:57:49 therve: what timings are you thinking of? 07:58:38 ramishra, Something like 5UTC / 15UTC? 07:58:47 I'll probably make a poll 07:59:04 k 07:59:10 5UTC will exclude a lot of europe unless they're early risers ;) 07:59:22 Well, yes 07:59:41 -> #heat 07:59:44 #endmeeting