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