20:00:08 #startmeeting heat 20:00:09 Meeting started Wed Mar 9 20:00:08 2016 UTC and is due to finish in 60 minutes. The chair is skraynev__. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:10 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:13 The meeting name has been set to 'heat' 20:00:18 #topic rollcall 20:00:23 o/ 20:00:31 hi 20:00:36 and me too 20:00:48 \o 20:01:01 :) 20:01:10 zaneb: ping 20:01:17 ramishra 20:01:17 hello 20:01:25 markvan: hi 20:01:27 oh hey it's that week 20:01:46 o/ 20:02:04 zaneb: yes :) 20:02:36 #topic Adding items to agenda 20:02:40 #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282016-03-09_2000_UTC.29 20:03:13 skraynev__: deprecating old heat commands 20:03:32 o/ 20:04:15 stevebaker: sure. added 20:04:59 #topic Using 1.0.0 heatclient for creating stable/mitaka branch 20:05:14 I think, that it's ok 20:05:46 and want to ask does anybody have another candidates ? 20:05:55 I haven't checked, is there any bug fixes in review or landed since 1.0.0 which justifies a 1.0.1? 20:06:31 stevebaker: honestly me too... 20:06:33 wait a se 20:06:35 I have the one template validate one out there 20:06:36 wait a sec 20:07:02 these have landed http://git.openstack.org/cgit/openstack/python-heatclient/commit/?id=7c1e7b05f44657e8ed59e2ec7f95c3c09e845226 http://git.openstack.org/cgit/openstack/python-heatclient/commit/?id=3da649d71480a89782e2d8e1d7d6c9069a1c4c78 20:07:10 #link https://review.openstack.org/#/c/288725/ 20:07:31 markvan: since that is a feature it will need to be in 1.1.0 20:08:18 stevebaker: I see 3 patches after 1.0.0 20:08:21 markvan: which can be released soon but I assume we've missed the boat to make heatclient stable/mitaka branch be based off a 1.1 20:08:21 is there an idea on when a 1.1.0 would be? is that aligned to Newton's release or not necessarily 20:08:23 1 - update requirements 20:08:33 2. https://github.com/openstack/python-heatclient/commit/7c1e7b05f44657e8ed59e2ec7f95c3c09e845226 20:08:39 3. https://github.com/openstack/python-heatclient/commit/3da649d71480a89782e2d8e1d7d6c9069a1c4c78 20:08:42 jdob: whenever we want to 20:08:46 kk 20:09:25 stevebaker: 1 is not important 20:09:32 3 is just fix for test 20:09:50 there is only one useful fix is 2 20:10:01 Fixed exceptions handling in stacks deleting 20:10:30 stevebaker: IMO it's strange to do 1.0.1 after one fix.... 20:10:32 and its a low impact issue, I'm fine with branching on 1.0.0 20:10:39 cool 20:10:41 ;) 20:11:35 then I will send reply to Doug about our decision 20:11:57 +1 20:12:50 #topic Heat installation issue 20:13:01 ping sam-i-am 20:13:10 skraynev__ for what it's worth, a 1.0.1 release (even for one fix) might be easier on packagers 20:13:22 (sorry, I got that comment in late; we can continue that in #heat) 20:13:48 jdob: I don't think that fix is worth it 20:14:14 doh 20:14:24 gotcha; I didn't actually look at it, that was just a general sentiment on whether or not to increment a .z release 20:14:26 it was network disconnect... 20:14:46 sam is not here 20:14:47 skraynev_ don't forge tto move back to skraynev__ to be able to end the meeting 20:15:09 (ran into that last week in tripleo's meeting) 20:15:11 I hope, that now it works again 20:15:33 you should be good to go 20:15:35 ok... then I just want to ask take a look on bug 20:15:53 #link https://bugs.launchpad.net/heat/+bug/1554533 20:15:53 Launchpad bug 1554533 in heat "Trustee sections should support auth_type option" [High,Confirmed] 20:16:49 shardy mentioned, that he left comment and... 20:17:10 it looks like we need more details for further work. 20:17:36 so I think we may skip this item and just talk about it tomorrow with shardy 20:17:48 #topic RC1 status 20:18:11 jdob: p.s. thx for the reminder about changing nick ;) 20:18:17 :) 20:18:21 #link https://launchpad.net/heat/+milestone/mitaka-rc1 20:18:36 rc1 is planned on the next week 20:19:26 our FFE is mostly ok. We wait merge patch for infra: https://review.openstack.org/#/c/287836/1 20:19:48 also please review https://review.openstack.org/#/c/237608/14 20:20:45 skraynev__: yup, I think those two are ready now, thx 20:21:04 experimental job for legacy engine works fine... 20:21:15 skraynev__: zoiks, waiting 130 minutes seems a little extreme 20:21:37 markvan: what about convergence case? I have seen, that it failed 20:21:49 by timeout. again ... 20:22:24 yeah, it has never gotten far enough to run the new test case 20:22:44 markvan: ok, so we don't know how long it takes to run yet? 20:22:49 130 is from what the current lbaas folks are using 20:23:07 stevebaker: yes. I know about it. as markvan teach me it happens due to long installation Octavia 20:23:10 Running it locally, it take 4-8 minutes (first spin up a lb) 20:23:42 yeah, adding octavia pushes devstack install >20 minutes 20:23:45 stevebaker: so as I understand we spent most time for devstack preparation 20:24:44 interesting, why does octavia take so long to install? 20:24:45 stevebaker. markvan: also I start thinking about running lbaas test in separate job in N 20:25:02 is it not on the test images already? 20:25:05 octavia downloads the amphora images 20:25:28 are amphora images hosted on openstack infra? 20:25:42 not sure 20:25:53 like here? http://tarballs.openstack.org/heat-test-image/ 20:27:41 I can check into those images 20:28:23 ok, 20 minutes is quite a hit, lets see what we can do about that 20:29:17 stevebaker: remember, that we have 1 week for it, so we need to do it soon ;) 20:29:22 markvan: ^ 20:29:44 so please pay attention on all suggestions on review 20:30:13 ok, we could raise the timeout for now. Maybe the timeout value can be templated so that other jobs that don't install Octavia can be lower 20:30:16 also I will start moving all high/medium bugs without assigner to N1 20:30:20 skraynev__, the RC1 bugs are accurate for Importance, right? i don't have anything on that list and should have time to take some on, I just wanted to double check that the high ones are actually high 20:32:01 jdob: there is one free High bug, which probably will be took by shrady... so I think your help will need with review 20:32:07 all in progress bugs 20:32:12 ok 20:32:33 also feel free to check statuses of not "In progress" bugs 20:33:01 if you think, that will be better to move some bug to N, please ping me and point on it 20:35:41 stevebaker: hm... I have left same comment about isolation existing jobs from timeout for lbaas v2 20:35:54 skraynev__: ok 20:36:00 markvan: can you do it in the same patch ^ ? 20:36:21 try to split it , I mean 20:36:37 I would rather do it with a follow up patch, to get the test running now 20:36:41 looks like more people want it, so I tend to ask you do it 20:37:22 What I worry about is that the lbaas v1 job is also timing out, but just not that often 20:37:52 markvan: but is it timing out due to failure or just taking a while to run 20:38:37 stevebaker: I did not see any failure in the ones I looked at, was about 90% thru the tests when it timed out 20:39:13 and the reason seemed to be a longer then usualy (<20 min) devstack install 20:39:49 so that could have been just a devstack install issue 20:40:27 markvan: ok, if those timeouts were not caused by a particular test stalling then it sounds like we need to raise the timeout in the short term and spend some effort on reducing run times next 20:41:27 yeah, I think once we get the test running, and see the actual times, it will help with the division of labor 20:41:47 markvan: how about two separate patches - increase timeout for small value, as stevebaker suggested and another patch with adding "special" timeout for lbaaas v 2 tests? 20:42:22 skraynev__: sure, I can do that 20:42:44 markvan: please post patches and add us on review ;) 20:42:51 #topic template-validate heat-template gate broke 20:43:06 #link https://bugs.launchpad.net/heat/+bug/1554380 20:43:06 Launchpad bug 1554380 in heat "heat-template zuul faliure" [High,New] - Assigned to Kanagaraj Manickam (kanagaraj-manickam) 20:44:01 the gate is using heat template-validate to run against all templates in the project 20:44:05 KanagarajM: is not here as I understand, but looks like his fix failed with another error 20:44:32 was using a hack to ignore the services not being there, only heat is available in this devstack. 20:45:01 Its possible we should make this job non-voting while we sort this out 20:45:09 markvan: ops. I missed, that fix was proposed by you. sorry 20:45:24 yeah, basic question, is there a way to "validate" all these templates without any more input? 20:45:29 and use human-eye based validation just so things can land again 20:46:04 and then fix gate and turn back it to voting... 20:46:05 stevebaker: yup, I think this needs to be non-voting or just disabled, as I don't think it was validating much to begin with. 20:46:23 markvan: I prefer temporary non-voting 20:46:36 markvan: lets make it non-voting - the validation of template structure was useful 20:46:39 validation is still need, IMO and should be fixed 20:46:49 k, I can push a patch for nv 20:46:58 markvan: yeah. please ;) 20:47:01 i thought template-validate intentionally didn't contact other services 20:47:20 #topic deprecation old CLI 20:47:42 stevebaker: do you want to discuss it as plan for N ? 20:47:48 jdob: possibly heat refactoring means validate and preview use the same validation paths 20:48:10 stevebaker: you are right. 20:48:12 stevebaker, ok, i'll ask you more after the meeting, since I was't sure if that was a bug or intentional 20:48:17 we need a plain for how to deprecate the old heat commands now that 1.0.0 is out 20:49:03 +1 stevebaker 20:49:05 stevebaker: what exactly you want clarify ? I think we may do it in the same way as keystone client 20:49:21 I suggest that someone puts together a commit which prints a deprecation warning that includes what the new command is 20:49:39 i.e. add some global warning with reference on openstack client 20:50:19 stevebaker: if nobody mind, we can take it 20:50:26 but I see no reason to have a plan for actually deleting the old commands. And old commands can get improvements as long as the new commands get the same improvements 20:51:12 stevebaker: in this case we need some short guide line like: if you improve osc, please add it to old cli ? 20:51:43 however my question is how should we update the docs which reference heat commands? Its going to take a while for 1.0.0 to propagate and be installed. When do pages like this switch over? http://docs.openstack.org/developer/heat/getting_started/create_a_stack.html 20:52:00 neelashah1, markvan: guys if you don't mind, I will take task with adding deprecation warnings. 20:52:25 skraynev__: k 20:52:37 neelashah1, markvan: but if we don't propose any chnges after week, feel free to do it ;) 20:52:44 markvan: thank you 20:52:45 skraynev__, if you are busy with RC stuff I can do it (i was going to volunteer for it too) 20:52:50 skraynev__: no, osc commands can improve without adding them to the old cli. But any change which improves the old cli needs a -1 review unless the osc command has the same thing 20:52:51 skraynev_ : Ok, thanks 20:53:25 stevebaker: and again, IMO, we should document this approach 20:53:35 stevebaker, what about simply saving the existing pages as < 1.0 and adding new pages with the 1.0 stuff? 20:53:48 probably wouldn't hurt to give all of those docs a read through for polishing up in the process 20:54:05 and then a link at the top of the pages "For < 1.0 client, click here" 20:54:07 stevebaker: yeah, but I still push back a bit on changing the old cli, unless good reason not to only go into osc 20:54:23 too bad we don't use readthedocs, I like their version support 20:54:37 stevebaker: I'd prefer to mention both cases : old CLI and new OSC 20:54:47 markvan: yeah, some pushback would be justified. Often they wouldn't even be aware of the new commands 20:55:36 markvan: except bug fixes, I suppose 20:56:02 yes, valid bugs are fine for a while 20:56:34 stevebaker: I think, that the best way is to add one page with all migrations old CLI ->> equal command in OSC 20:56:45 jdob: there is the cli-reference too, http://docs.openstack.org/cli-reference/heat.html 20:56:47 and then update old pages by using new OSC 20:57:31 skraynev__ i like the idea of a one page guide for existing users 20:57:37 skraynev__: like have a note at the top of any page which has heat commands pointing them to the mapping if they don't have 1.0.0 yet 20:57:53 stevebaker: +1 20:58:08 stevebaker, so oyou're ok with a "look at this mapping" instead of having both side by side in the same docs? I agree with that 20:58:20 i'd like to avoid mixing them on the same page 20:58:36 jdob: yeah, side by side would be some clutter 20:58:58 skraynev__: fyi I added patch to cli doc to have in include ocs plugins (include new heat), just need to get versions bumped now to pick it up 20:58:59 #action Add a page to http://docs.openstack.org/developer/heat/#using-heat for new cli -> old cli mapping 20:59:40 skraynev__: all of it will it gen'd from the cli help and will appear under the ocs page 21:00:05 markvan: where is this page? 21:00:08 times up 21:00:15 stevebaker, what about the larger effort of updating all of the pages? is that going to be a blueprint? spec-lite? 21:00:25 stevebaker: #link http://docs.openstack.org/cli-reference/openstack.html 21:00:43 jdob: bah, lets just do it 21:00:57 kk, lemme know if i can help out and how you'd want to coordinate that 21:01:15 ok, we should end this and skraynev seems to be having network issues 21:01:19 it's #endmeeting right? 21:01:25 jdob: yes 21:01:29 we're not the chair 21:01:35 stevebaker: #link https://review.openstack.org/#/c/256117/ 21:01:36 markvan: patch 256117 - openstack-doc-tools - Add additional openstack client plugins (MERGED) 21:01:36 I know :( 21:01:40 oh, there you are, I was gonna move to skraynev__ and do it 21:01:51 i've seen that work before :) 21:02:13 jdob: not for now :((( 21:03:06 so what's going on? 21:03:39 notmyname: hi. sorry. I had a network issue and was disconnected as result I can not relogin with correct nick name 21:03:45 o/ 21:03:46 and end meeting :( 21:03:47 fun 21:03:55 notmyname: YEAH 21:03:58 there you go 21:04:09 #endmeeting