06:59:37 <skraynev> #startmeeting heat
06:59:38 <openstack> Meeting started Wed Sep 30 06:59:37 2015 UTC and is due to finish in 60 minutes.  The chair is skraynev. Information about MeetBot at http://wiki.debian.org/MeetBot.
06:59:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
06:59:41 <openstack> The meeting name has been set to 'heat'
06:59:52 <skraynev> #topic rollcall
07:00:22 <tspatzier> hi all
07:00:29 <ramishra> hi
07:00:32 <sirushti> o/
07:00:32 <KanagarajM> hi
07:00:46 <rakesh_hs> o/
07:00:50 <pas-ha> o/
07:01:26 <skraynev> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282015-09-30_0700_UTC.29
07:01:44 <skraynev> #topic Adding items to agenda
07:01:59 <stevebaker> \o
07:02:10 <skraynev> we have a short agenda now.
07:02:20 <skraynev> does anybody want to add something ?
07:02:25 <stevebaker> skraynev: liberty rc2 status
07:03:16 <skraynev> stevebaker: done
07:03:28 <skraynev> let's start from this :)
07:03:45 <skraynev> #topic liberty rc 2 status
07:04:01 <stevebaker> the update is that there is no update ;)
07:04:06 <ramishra> lol
07:04:08 <skraynev> :)
07:04:10 <stevebaker> rc2 window isn't open yet
07:04:25 <stevebaker> but we will need an rc2 since we have a regression on nova-network
07:04:32 <skraynev> ttx said, that swift has not rc-1 yet...
07:04:49 <skraynev> so probably rc2 will be only on the next week
07:05:09 <stevebaker> and once the window opens I'd like a lot of these to be backported, so get your cherry-pick fingers ready https://bugs.launchpad.net/heat/+bugs?field.tag=liberty-rc-potential
07:05:36 <stevebaker> that is all
07:05:39 <skraynev> stevebaker: +1
07:06:14 <skraynev> stevebaker: thx for the update
07:06:23 <stevebaker> np
07:06:25 <pas-ha> some of those not merged yet :(
07:06:33 <skraynev> #topic Heat Gate state
07:06:44 <skraynev> pas-ha: because of ^
07:06:55 <pas-ha> skraynev, yeah
07:07:03 <skraynev> ramishra: I have seen that tempest patch was merged
07:07:24 <ramishra> skraynev:  yep
07:07:26 <skraynev> and fix for our gate was approved too
07:07:59 <skraynev> looks like gate will unblock soon
07:08:21 <pas-ha> the parallel SD test is also failing quite a lot
07:08:30 <skraynev> ramishra: ceilometer issue also was solved by patch from sirushti
07:08:34 <pas-ha> the functional one that is
07:08:54 <stevebaker> pas-ha: we think that is a duplicate with another gate-failure bug
07:09:10 <skraynev> pas-ha: AFAIK, ramishra may shed a light on it too
07:09:13 <ramishra> pas-ha:  I think it's the same as https://bugs.launchpad.net/heat/+bug/1498495
07:09:13 <openstack> Launchpad bug 1498495 in heat "ActionInProgress_Remote: Stack TemplateResourceUpdateFailedTest already has an action (CREATE) in progress." [High,In progress] - Assigned to Rabi Mishra (rabi)
07:09:40 <ramishra> http://logs.openstack.org/96/228796/3/check/gate-heat-dsvm-functional-orig-mysql/e013ae4/logs/screen-h-eng.txt.gz?level=ERROR#_2015-09-30_02_11_42_318
07:09:55 <ramishra> I can see the same errors for this test.
07:10:08 <stevebaker> https://review.openstack.org/#/c/227156/ is ramishra's fix
07:10:10 <skraynev> pas-ha: so review for https://review.openstack.org/#/c/227156/3 potentially solves issue
07:10:27 <pas-ha> ok, got it, will check it out
07:10:44 <skraynev> I plan to look on it today, but if somebody else do it first - it will be awesome :)
07:10:53 <pas-ha> we need to merge one patch to merge another patch to unblock heat-templates gate..
07:11:27 <skraynev> oh. right
07:11:50 <skraynev> pas-ha: could you give update about your work related with fixinf heat-templates gate
07:11:56 <skraynev> *fixing
07:12:24 <pas-ha> so, this one allows many-to-one mapping in environments  https://review.openstack.org/#/c/227875/
07:13:05 <pas-ha> and this one maps (almost) everything in heat-templates to OS::Heat::None https://review.openstack.org/#/c/227703/
07:13:59 <pas-ha> but we have another parallel bug on heat templates gates where cyclic dependencies are now get caught by template-validate for some templates
07:14:16 <KanagarajM> after shardys fix on the template validation to align with stack creat action, there are some templates fails with circular reference error , so trying this https://review.openstack.org/#/c/226244/
07:14:46 <pas-ha> probably I would have to squash KanagarajM fix and mine in one commit
07:14:58 <stevebaker> so those templates with cyclic deps were broken anyway?
07:15:04 <pas-ha> yep
07:15:12 <stevebaker> good catch
07:15:32 <KanagarajM> pas-ha: yes, but seems there are some other issue, that once heat-template build fails, http://logs.openstack.org/44/226244/3/check/gate-heat-templates-dsvm/8df60b1/logs/devstack-gate-setup-workspace-new.txt.gz#_2015-09-23_06_33_50_036
07:16:06 <pas-ha> how about we just delete them?
07:16:18 <pas-ha> or indeed try to rework and remove cucles
07:16:56 <KanagarajM> pas-ha: i didn't know how to remove the circular ref in those templates, so thought of tagging them as invalid.
07:17:07 <skraynev> pas-ha: is it possible to fix them in short time frame?
07:17:18 <pas-ha> I will take a look
07:17:39 <KanagarajM> but this build error mentioned above seems to be different
07:17:44 <skraynev> KanagarajM: but now looks like you just remove them or not ?
07:18:01 <stevebaker> I would say there is nothing useful in any cfn/F17 template ;)
07:18:07 <pas-ha> no, they are moved to special folder that does not get validated
07:18:27 <pas-ha> stevebaker, easy fix then :)
07:18:36 <pas-ha> kill'em in fire
07:18:53 <KanagarajM> yes, i tried that way, moving them to invalid , but above error needs to be fixed too
07:19:18 <KanagarajM> it looks like some jenkins job git related error
07:19:59 <KanagarajM> sirushti: did you get chance to look at it ?
07:20:04 <skraynev> stevebaker: sounds like a first step for deprecation AWS resources :)
07:20:45 <stevebaker> I *suppose* they're useful to keep around for checking on heat validation regressions
07:20:57 <stevebaker> just not the invalid ones
07:21:21 <pas-ha> like a separate validate call that must fail?
07:22:02 <stevebaker> hmm, maybe not
07:22:04 <sirushti> KanagarajM, not yet, best ask the infra team for that
07:25:31 <skraynev> ok. As I understood pas-ha: will provide squashed fix
07:25:39 <stevebaker> FYI, RC2 opens early next week, you heard it here first
07:25:59 <KanagarajM> sirushti: ok sure
07:26:02 <ramishra> gate is  unblocked:)  push the recheck buttons;)
07:26:19 <skraynev> and sirushti or KanagarajM : will investigate issue with "git"
07:26:32 <skraynev> ramishra: super. thank you :)
07:26:56 <KanagarajM> skraynev: sure. i will try to check with infr team
07:27:07 <skraynev> KanagarajM: thank you ;)
07:27:24 <skraynev> ok. got to the next topic
07:27:39 <skraynev> #topic Separate job for services under Apache
07:28:11 <skraynev> during L we did most part of necessary work to make it work
07:28:43 <skraynev> so now will be really useful to make sure, that it works for tempests tests
07:29:16 <skraynev> how about adding separate tempest job with api services launched under Apache ?
07:30:13 <stevebaker> maybe we could just switch gate-tempest-dsvm-heat to apache and leave gate-heat-dsvm-functional as is?
07:31:00 <pas-ha> btw, not sure how sighup func tests would behave on api under apache
07:31:19 <skraynev> sounds like a strong way... how about soft migration plan
07:31:32 <skraynev> separate non voting job with same bunch of tests ?
07:31:58 <stevebaker> we could start with an experimental job rather than non-voting
07:31:59 <skraynev> when we make sure, that it works we switch our main job to Apache
07:32:20 <skraynev> stevebaker: yeah right. experimental is better
07:33:21 <skraynev> experimental -> stable works experimental -> replacing gate-tempest-dsvm-heat
07:34:01 <skraynev> gate-heat-dsvm-functional - agree, let's leave it without any changes
07:34:24 <stevebaker> sounds like a plan
07:34:45 <skraynev> good.
07:34:58 <skraynev> #topic Open discussion
07:35:49 <sirushti> so, just a heads up, there will be a non-voting heat-dsvm-functional job for python34
07:36:50 <sirushti> so, that's going to be running the integration test suite against heat running on the python3.4 interpreter
07:36:59 <skraynev> sirushti: with enabled convergence ? :)
07:37:17 <pas-ha> I also had an idea to lessen the burden on the gates and follow Ironic/Neutron/Swift approach - if the patch only touches docs/unit tests - run only pep8/pyXX gates
07:37:44 <pas-ha> and docs
07:37:48 <sirushti> skraynev, just the legacy one for now, maybe an experimental job for convergence?
07:37:55 <pas-ha> and if only docs are touched - only docs/pep8
07:38:07 <stevebaker> permutation explosion! py27/py34, mysql/postgres, apache/wsgi, convergence/classic
07:38:18 <pas-ha> yay!
07:38:24 <sirushti> heh
07:38:32 <skraynev> sirushti: I personally think, that if we officially announce, that totally support py34 - we should have non-voting for py34
07:39:06 <sirushti> sure, a non-voting job is in the pipeline for Heat btw -> https://review.openstack.org/#/c/228194/
07:39:09 <sirushti> skraynev, ^
07:39:21 <skraynev> sirushti: for default will be enough for now
07:39:22 <stevebaker> sirushti: does this mean that devstack can choose some services to run under py34?
07:39:56 * stevebaker wants to switch
07:39:58 <sirushti> stevebaker, yup, so I'm still reworking that patch -> https://review.openstack.org/#/c/181165/
07:40:18 <sirushti> stevebaker, so if a service consists of the necessary trove classifiers
07:40:55 <stevebaker> sirushti: very nice
07:40:59 <sirushti> stevebaker, devstack install the python3 version of that service to /usr/local/bin i
07:41:09 <skraynev> stevebaker: do you mean switch all jobs ?
07:41:17 <stevebaker> skraynev: no, for local dev
07:41:23 <skraynev> pas-ha: I like this idea
07:41:40 <skraynev> pas-ha: welcome with patch for this stuff
07:41:46 <pas-ha> ok
07:41:53 <sirushti> pas-ha, agreed!
07:42:54 * skraynev imagine Tokyo announce: "Heat totally migrate on py34..." with other Openstack on py27 :)
07:42:56 <stevebaker> pas-ha: I think there are a couple of mechanisms in project-config to do that
07:43:10 <pas-ha> I know, already saw them
07:45:33 <pas-ha> though I might get troubles writing a regex for all our zoo of job names :)
07:46:45 <skraynev> pas-ha: good chance to rename them and make more clear for newcomers :)
07:46:59 <skraynev> or maybe not so clear as it's :)
07:48:38 <skraynev> Also during yesterday meeting with release team was mentioned mail: http://lists.openstack.org/pipermail/openstack-dev/2015-September/075608.html
07:49:17 <skraynev> I have not read it yet. Need to make sure, that our deprecation process is corresponding.
07:50:12 <stevebaker> I've not read it either, but I'm guessing our current practice is close enough to it that we should go for the tag
07:51:14 <skraynev> stevebaker: yeap. I think so too.
07:51:43 <pas-ha> Just skimmed through, we are close enough
07:51:52 <pas-ha> only not sure how we relate to defcore
07:51:57 <skraynev> also on desert two links on cross-project specs: https://review.openstack.org/226157 Backwards compatibility for clients and libraries
07:52:38 <skraynev> Service Catalog Standardization  https://review.openstack.org/181393
07:54:27 <skraynev> pas-ha:as I understand they have list API which should be covered by tests... I suppose, that stevebaker knows more about it
07:55:38 <stevebaker> pas-ha: defcore? the process has started, but will be on hold until we figure out how to handle the contradiction of defcore tests being in tempest, and tempest encouraging tests to be moved in-tree
07:56:19 <stevebaker> pas-ha: there was a mail on openstack-dev not so long ago
07:56:37 <ramishra> stevebaker: Is there a plan to move the api tests in-tree in the near future?
07:56:53 <skraynev> ramishra: looks like patch for cinder also need for Liberty, I added tag liberty-rc-potential. Could you upload a backport for this patch ?
07:57:10 <hogepodge> stevebaker: if a test is defcore, qa would like it to stay in tempest. That may not be feasible in the long run, especially with test maintenance. In that case, being able to run the test as a plugin to tempest is a suitable alternative
07:57:49 <ramishra> skraynev:  ok
07:57:53 <hogepodge> there's definitely a tension there, but a preference to have interop tests be in tempest.
07:58:01 <stevebaker> pas-ha, ramishra: http://lists.openstack.org/pipermail/openstack-dev/2015-September/075033.html
07:58:45 <skraynev> ramishra: I wanted to discuss this plan during session in summit :) as I understand we need to add some tests for API in our Heat repo. migrate all functional tests to use tempest-lib and also remove duplicate tests between tempest and our internal integration tests
07:59:22 <stevebaker> hogepodge: sure, but in my ideal scenario our defcore tests are developed in-tree then moved to tempest. So I'd like to look at us porting our tests to tempest-lib so moving tests is painless
08:00:23 <stevebaker> timezup
08:00:29 <ramishra> yep
08:00:29 <pas-ha> time's up
08:00:29 <skraynev> yeah.
08:00:33 <skraynev> #endmeeting