20:00:06 <skraynev_> #startmeeting heat
20:00:07 <openstack> Meeting started Wed Oct  7 20:00:06 2015 UTC and is due to finish in 60 minutes.  The chair is skraynev_. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:11 <openstack> The meeting name has been set to 'heat'
20:00:19 <skraynev_> #topic rollcall
20:00:21 <stevebaker> \o
20:00:55 <prazumovsky> Hello!
20:00:58 <jdob> o/
20:01:01 <shardy> o/
20:01:04 <markvan> hi
20:01:09 <tspatzier> hi
20:01:32 <pas-ha> o/
20:01:43 <skraynev_> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282015-10-07_2000_UTC.29
20:02:03 <skraynev_> let's start :)
20:02:15 <skraynev_> #topic Adding items to agenda
20:02:33 <skraynev_> some additional items ?
20:03:51 <zaneb> o/
20:03:53 <markvan> new lbaas v2 spec, would like to discuss how to handle with existing v1 support
20:04:04 <markvan> for integration testing
20:05:09 <skraynev_> markvan: ok. added
20:05:23 <skraynev_> move to the next
20:05:34 <skraynev_> #topic liberty rc2 status/ backporting hot fixes
20:05:35 <stevebaker> #link https://launchpad.net/heat/+milestone/liberty-rc2
20:05:45 <skraynev_> stevebaker: thx :)
20:05:58 <skraynev_> looks like most part was merged
20:06:17 <stevebaker> there is nothing of consequence left in liberty-rc-potential https://bugs.launchpad.net/heat/+bugs?field.tag=liberty-rc-potential
20:06:40 <stevebaker> I suppose https://bugs.launchpad.net/heat/+bug/1491773 could be backported, stable gates is good
20:06:40 <openstack> Launchpad bug 1491773 in heat "gate fails on test_nested_stack_adopt_fail" [Medium,Fix committed] - Assigned to Angus Salkeld (asalkeld)
20:06:58 <skraynev_> stevebaker: +1
20:07:36 <stevebaker> we should look at https://bugs.launchpad.net/heat and see if anything else is worth putting in rc2, but generally we're looking in good shape
20:07:42 <skraynev_> I plan take a look this one  tomorrow https://bugs.launchpad.net/heat/+bug/1498660
20:07:42 <openstack> Launchpad bug 1498660 in heat "Convergence: test_stack_update_replace_with_ip_rollback failure" [High,In progress] - Assigned to Rakesh H S (rh-s)
20:08:03 <zaneb> stevebaker: but we can get the benefit of stable gates any time without waiting for a release, so it's nbd for rc2
20:08:23 <stevebaker> zaneb: true dat
20:09:24 <skraynev_> AFAIK, we have a rc for all projects and release will happen on the next week
20:09:35 <skraynev_> need to chat with ttx about it
20:10:13 <zaneb> whoa
20:10:16 <zaneb> https://git.openstack.org/cgit/openstack/heat/commit/?id=d07f91615a159663261091e672ce62f90e6ad607
20:10:20 <stevebaker> oh, I've put the release notes in, its a bit of a novel :) https://wiki.openstack.org/wiki/ReleaseNotes/Liberty#OpenStack_Orchestration_.28Heat.29
20:10:30 <zaneb> did we seriously backport a DB migration to kilo?
20:11:21 <zaneb> maybe it was during the RCs
20:11:21 <skraynev_> stevebaker: looks nice! thank you ;)
20:11:48 <skraynev_> zaneb: probably - yes
20:11:48 <shardy> zaneb: I think it must've been or it wouldn't have been +A'd by ttx?
20:11:51 <stevebaker> zaneb: the author and committer dates are close
20:12:08 <zaneb> ah
20:12:10 <zaneb> tags: 	removed: kilo-rc-potential
20:12:14 <zaneb> so yes
20:12:32 <skraynev_> #topic heat-templates gate fixing progress
20:12:37 <zaneb> it just wasn't targeted for Liberty, which is why it doesn't say Fix Released
20:12:48 <skraynev_> update - it was fixed ;)
20:12:58 <stevebaker> #link https://bugs.launchpad.net/heat/+bugs?field.tag=gate-failure
20:14:03 <skraynev_> I mostly say about job for heat-templates repo
20:14:21 <pas-ha> well, the current fix for haet-templates gates just ignores the errors in notfound endpoints
20:14:49 <stevebaker> oh, heat templates. I can't read
20:14:55 <shardy> stevebaker: I might add a bullet to the API additions saying PATCH is now fully implemented, if that's OK with you
20:15:03 <skraynev_> btw most part of these ^ bugs look like hard-reproducible
20:15:05 <stevebaker> shardy: yeah, do it
20:15:52 <skraynev_> shardy: good point ;)
20:16:08 <skraynev_> pas-ha: do we need another workaround ?
20:16:17 <pas-ha> on the review https://review.openstack.org/#/c/227875/
20:16:37 <pas-ha> but shardy had some suggestions I still haven't implemented
20:17:35 <pas-ha> shardy, I remember we were talking this over on irc, would you mind put your ideas on gerrit?
20:17:55 * pas-ha has things escaping his attention
20:18:03 <shardy> pas-ha: sure will do
20:18:23 <pas-ha> thanks
20:18:48 <skraynev_> pas-ha: thank you for the update ;)
20:18:53 <pas-ha> np
20:19:12 <skraynev_> #topic review exception for automation translation commits (+2A)
20:19:28 <pas-ha> let'em merge and don;t bug us?
20:19:54 <stevebaker> yep, just like requirements changes, one core can approve
20:19:58 <skraynev_> it's patches introduced by Bot
20:20:18 <zaneb> +1
20:20:19 <skraynev_> stevebaker: for requirements - not totally sure
20:20:47 <stevebaker> skraynev_: that core should still check the requirements change for sanity
20:20:56 <pas-ha> yes, I remember several times e.g. shardy new something bad about new lib versions we did not..
20:21:11 <shardy> +1 but yeah there have very occasionally been bogus requirements bot proposals
20:21:15 <skraynev_> sometimes it make affect us. I remember situation, when Jason asked me about delay for approve some requirements update patch
20:21:19 <shardy> so worth paying attention ;)
20:21:31 * shardy remembers proposals from wrong branches
20:21:42 <zaneb> nobody reads the translations anyway though
20:22:02 <pas-ha> definitely +1 for translations
20:22:03 <skraynev_> zaneb: :) it's true ...
20:22:33 <shardy> Yeah it's impossible to effectively review the translations anyway other than checking what files are touched
20:22:43 <pas-ha> I would even suggest keep translations in a separate repo and pull it as submodule
20:23:15 <pas-ha> and let translation team/bot merge to the separate repo at their will
20:24:12 <skraynev_> pas-ha: could you ask about it in openstack-dev or translation team directly?
20:24:39 <pas-ha> ok, will try. I just know many people do not like git submdules
20:24:57 <skraynev_> Anyway looks like we come to agreement - one core may approve translation patch
20:25:19 <skraynev_> pas-ha: hope on you ;)
20:25:35 <shardy> skraynev_: +1
20:25:41 <skraynev_> #topic mox3 vs mock in unittets
20:26:19 <skraynev_> we have this patch https://review.openstack.org/#/c/230300/
20:26:23 <pas-ha> that's an interesting one. I honestly hate mox, and do not think mox3 is any better in general
20:26:34 * shardy is only just recovering from the mox->mock shift
20:26:48 <pas-ha> so if this patch fixes some real issue - we should merge it
20:27:10 <skraynev_> what do you think about attempt for total migration during M?
20:27:19 <stevebaker> isn't mox3 just a non-abandoned fork of mox which works on python3?
20:27:26 <pas-ha> only if there are volonteers for that
20:27:26 <zaneb> pas-ha: it's not worse though, is it
20:27:32 <skraynev_> I know, that it's difficult and boring...
20:27:33 <pas-ha> not
20:28:15 <zaneb> converting also makes backports an even bigger giant pain
20:28:20 <pas-ha> it's only plus it is "owned" by openstack community so that we in principle can fix things faster
20:28:25 <zaneb> just throwing that in there
20:28:49 * zaneb just finished the most painful backport ever last night
20:28:49 <jdob> i'd be willing to help out with the conversion to mock
20:28:53 <stevebaker> if someone wants to convert our tests they should go for it, but I see no issue with doing mox->mox3 in the meantime
20:29:03 <zaneb> stevebaker++
20:29:20 <pas-ha> on the other hand, patch looks small, so why not
20:29:41 <stevebaker> pas-ha: exactly
20:29:48 <skraynev_> stevebaker: maybe we may create bp for this work to make this work more official ?
20:29:52 <pas-ha> if it might help running py34 gate in the future - even better
20:30:12 <pas-ha> nah, just convert them case-by-case
20:30:31 <pas-ha> those for a change are more or less independent
20:30:43 <shardy> using it sounds fine, provided we're not going to have another giant shift to a different tool
20:30:54 <shardy> our tests are already a mess of mox/mock mixture
20:31:02 <pas-ha> I doubt it, mock is in stdlib
20:31:11 <pas-ha> of py3
20:31:21 <stevebaker> yeah, mock isn't going away
20:31:24 <zaneb> stevebaker and I just left exactly the same comment at the same time
20:31:34 <shardy> Ok, cool
20:31:47 <stevebaker> zaneb: I used less words
20:32:04 <zaneb> you win this time baker
20:32:19 <pas-ha> btw, if we are going to change tests en masse - should we skip the func gates on pyX jobs?
20:32:33 <pas-ha> ironic does that, also neutron and somebody else..
20:32:38 <skraynev_> zaneb: lol
20:33:10 <pas-ha> i mean skip if only unit tests are changed
20:33:18 <stevebaker> pas-ha: I would -2 large changes, fine grained changes please
20:33:41 <stevebaker> pas-ha: oh, I see
20:33:54 <pas-ha> no, I mean if a patch set only touches heat/tests/* - run only pep8 and pyXY
20:33:58 <stevebaker> pas-ha: another orthogonal issue which would be nice to have
20:34:19 <stevebaker> pas-ha: same for docs changes
20:34:27 <pas-ha> yes
20:35:02 <skraynev_> pas-ha: I ready to +2 such changes :) but suppose, that it will be different repo  :(
20:35:21 <pas-ha> yes, project-config it is
20:35:49 <skraynev_> pas-ha: I expected something like that :)
20:36:32 <skraynev_> anyway, I agree with it. looks reasonable especially in light of migrating mox to mock
20:37:29 <skraynev_> so my favorite ...
20:37:33 <skraynev_> #topic Tokyo summit sessions
20:38:23 <skraynev_> we have less sessions, then time slots ;)
20:38:24 <skraynev_> https://etherpad.openstack.org/p/mitaka-heat-sessions
20:38:28 <skraynev_> #link https://etherpad.openstack.org/p/mitaka-heat-sessions
20:38:37 <skraynev_> https://mitakadesignsummit.sched.org/overview/type/heat#.VhV05dSlykp
20:38:42 <skraynev_> #link https://mitakadesignsummit.sched.org/overview/type/heat#.VhV05dSlykp
20:39:15 <skraynev_> need a brainstorm with raising ideas for discussions :)
20:39:34 <skraynev_> discussions == sessions
20:39:57 <skraynev_> any thought are welcome
20:40:49 <skraynev_> otherwise it will be convergence Phase * :)
20:41:11 <zaneb> lol
20:41:40 <shardy> The crazy large sahara clusters one is interesting, I'd be interested in hearing more about that ahead of the summit
20:42:26 <skraynev_> We may re-sort and split this topic on maximum 2 or 3 sessions
20:42:35 <stevebaker> A general session on handling large stacks would be good, and we can cover sahara needs in that
20:42:38 <skraynev_> but... it's still not enough
20:42:39 <shardy> Some of that sounds similar to issues encountered by TripleO
20:42:49 <shardy> stevebaker: +1
20:43:21 <skraynev_> stevebaker: is it separate cross-project session ?
20:43:24 <shardy> with some definition of "large", and perhaps folks can describe their observed performance, heat deployment scale and bottlenecks
20:43:26 <tspatzier> I recently discussed the relation between heat and senlin with Qiming. One point is whether senlin could at some point be used transparently as scaling driver underneath current ASG resources. Just as thought, and would need input from Qiming
20:43:49 <stevebaker> skraynev_: scaling large stacks? That sounds more heat-specific
20:43:58 <shardy> skraynev_: I think it's mostly heat specific
20:44:15 <shardy> large resource groups, deep nesting etc
20:44:25 <shardy> but there is the nova can't cope issue referenced as well
20:44:39 <shardy> e.g the batched create thing
20:45:53 <shardy> tspatzier: +1 revisiting the autoscaling discussion would be good, particularly in the light of the steps towards an internal scaling/group lib made by zaneb and ramishra
20:46:04 <skraynev_> stevebaker: shardy: is it number 7 ? or you mean add new one ?
20:46:18 <shardy> and, status of Senlin too, not heard much about that lately
20:46:22 <zaneb> add a new one
20:46:26 <zaneb> +1
20:46:53 <skraynev_> tspatzier: agree with shardy, please add it ;)
20:46:58 <shardy> skraynev_: Yeah IMO it's a new one, AutoScaling/Group architecture/roadmap
20:47:07 <stevebaker> skraynev_: we can add overlapping duplicates now, and you get to de-duplicate into available session slots ;)
20:47:18 <tspatzier> skraynev_, I'll do
20:47:37 <skraynev_> shardy: ok. could you add this one?
20:48:00 <shardy> skraynev_: added #14
20:48:01 <skraynev_> stevebaker: yeah. I like this way :)
20:49:01 <skraynev_> fuh :) now it looks more interesting
20:49:12 <skraynev_> shardy: thx
20:49:47 <tspatzier> shardy was quicker than me
20:49:50 <shardy> Does hooks and notifications include user-visible warnings?
20:49:59 <skraynev_> if you have other idea, to not hesitate to add them :)
20:50:16 <shardy> I was discussing that today in the context of how you can deprecate/rename stack parameters, if you expect them to be widely consumed
20:50:30 <shardy> I can add another item on that if needed
20:50:43 * shardy adds & we can merge
20:50:56 <skraynev_> :)
20:51:11 <skraynev_> ok. last one item in agenda
20:51:15 <skraynev_> #lbaas spec v2
20:51:38 <skraynev_> markvan: ping
20:51:40 <markvan> hi, with new lbass v2 resources coming: https://review.openstack.org/#/c/230197/
20:52:11 <markvan> was wondering about how to handle the heat integration tests with devstack. It seems that with v2 enabled, v1 has to be disabled.
20:52:59 <markvan> so, that would mean current autoscale lb scenario for v1 would need to be skipped when trying to run the lbaas v2 scenario.
20:53:17 <markvan> Trying to understand how to best handle this type of case
20:53:29 <skraynev_> does neutron allow to configure both versions of lbaas plugin in the same time?
20:53:50 <skraynev_> if not - we can not do it on the gate too
20:54:07 <markvan> I did not think so, but I will have to confirm that.  For devstack, it seems the answer is no.
20:54:36 <stevebaker> skraynev_: if I end up driving a docs and heatclient session then I wouldn't necessarily want to drive the testing one
20:56:11 <pas-ha> markvan, gates are running on devstack as well
20:56:23 <skraynev_> stevebaker: sorry, I am not sure, that understood you. could you re-phrase please ?
20:56:52 <markvan> skraynev_: would it be possible to run a second interation of the integartion test to allow for this new
20:56:52 <markvan> lbaas v2 environment?
20:57:27 <markvan> basically setup new devstack with v2 enabled and v1 disabled
20:57:46 <pas-ha> not sure it would be wise to spin up an extra gate job for just couple of tests..
20:57:47 <skraynev_> markvan: I'd suggest to add experimental job for it.
20:58:03 <stevebaker> skraynev_: I'm potentially a Driver for 3 of the sessions and I'm trying to share the love
20:58:39 <skraynev_> stevebaker: oh :) np. I am ready to take part of it ;)
20:59:04 <markvan> skraynev_: yeah, that would work.   At some point I would think the old lbaas v1 will be deprecated and removed, then devstack will have v2 enabled by default for testing this.
20:59:10 <pas-ha> markvan, is it possible to understand the version of lbaas by quering keystone catalog or the API itself?
20:59:47 <skraynev_> 1 minute left
20:59:58 <markvan> pas-ha: I think it's possible by calling into the neutron api, to see if that lbaas v2 extension is enabled.
20:59:59 <shardy> pas-ha: +1 it must be possible to somehow detect that, and conditionally skip
21:00:17 <zaneb> skraynev_: looks like we solved your more-slots-than-sessions problem
21:00:18 <stevebaker> markvan: I would make them separate tests, and use the conf file to enable the one that has the enabled endpoint
21:00:27 <skraynev_> #endmeeting heat