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