15:03:31 #startmeeting heat 15:03:33 Meeting started Wed May 3 15:03:31 2017 UTC and is due to finish in 60 minutes. The chair is ricolin. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:03:34 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:03:36 The meeting name has been set to 'heat' 15:03:43 #topic roll call 15:04:09 hi 15:04:20 hi ramishra:) 15:04:28 hello 15:04:35 howdy 15:05:36 #topic adding items to agenda 15:05:43 #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282017-05-03_1500_UTC.29 15:07:33 #topic Boston sessions broadcast 15:07:49 so we have three-four sessions in Boston 15:08:20 Heat project update 15:08:28 #link https://docs.google.com/presentation/d/1NiwYC3K04VIozZOk3_41_GnWMQUMxD8XhxiySEl6Ayw/edit?usp=sharing 15:08:40 Heat on-boarding 15:08:44 #link https://docs.google.com/presentation/d/1U-UDIdVHvP8jyzoZUo_3OIW-lvwDw2zfS2yynoFhwng/edit#slide=id.g1de11d5325_0_45 15:08:59 Large Orchestration Stacks 15:09:39 and one left is the application discussion 15:09:54 #link https://www.openstack.org/summit/boston-2017/summit-schedule/events/18951/cloud-aware-application-support 15:10:07 those slide still WIP 15:11:12 but feel free to put your though in side since we hope it can represent what heat team's doing 15:11:42 #topic API-WG liaison 15:11:54 #link http://specs.openstack.org/openstack/api-wg/liaisons.html 15:12:14 seems we needs a API-WG liaison 15:12:55 I will do it if no volunteer 15:13:10 We do have a name there;) 15:14:01 and TBH I don't even know who he is... 15:14:34 He has moved to different things now:) 15:14:35 zaneb should know:) 15:14:51 yeah, I think so too:) 15:15:07 ricolin: he was part of our team at RH, but he transferred to work on Ansible about a year ago 15:15:59 cool 15:17:13 I will take the API-WG liaison, and feel free to take over from me if you think it's a fun thing to do!!!:) 15:17:48 #action ricolin will act the API-WG liaison 15:18:33 #topic gate change 15:18:50 #link https://review.openstack.org/#/c/461968/ 15:18:55 #link https://review.openstack.org/#/c/462041/ 15:19:10 We have two propose change 15:19:23 from ramishra and therve 15:19:41 Yeah I'm not crazy about it 15:19:59 I don't see why we have to put in the gate, making we can keep it non voting 15:20:55 so the one I proposed is an indentity-v3 job change, it was a job running tempest tests, so I changed to run integration tests 15:21:13 It's a non-voting job too 15:21:42 therve: because it can be testing a different thing when it merges, and if you merge something broken then check jobs on everything else will fail from that point on 15:21:49 https://review.openstack.org/#/c/461823/ would break it 15:21:55 therve seems it's a strict requirement there 15:22:40 zaneb, How different though? 15:22:50 I don't see a scenario where that would make a difference here 15:23:00 I mean the dependant one in that DNM patch 15:23:08 therve: different by whatever has changed on master between when the check job and the gate job runs 15:23:29 * therve shrugs 15:23:35 therve: if that interacts with your patch then the check job is broken 15:26:28 ramishra your patch also remove tempest out of the job right? 15:27:06 ricolin: it removes the tempest tests, not tempest 15:27:56 ramishra, yes! right! 15:28:34 ramishra, `orchestration` tempest test 15:28:39 we had the job template(normal dsvm job with the special flag), so just changed the job name 15:29:17 ricolin: yes 15:29:56 so is everyone fine with remove those tempest test out? 15:29:59 +1 from me 15:31:05 it sounds like approve to me:) 15:31:20 #topic Remove test from tempest 15:31:25 #link https://review.openstack.org/#/c/461841/ 15:31:59 and after we remove those tests, tempest can remove those tests out of tempest 15:32:59 do we have replacements for those tests somewhere? 15:33:32 no 15:33:54 I've been responding to tha ML thread, so IMO, whether to keep those tests in tempest tree or not is tempest teams call. 15:34:32 IMO, we would not like to create a separate repo with those and own it 15:34:44 ramishra, yeah, and they try to notify us if that change will break anything:) 15:34:54 those tests are pretty old 15:34:54 zaneb: the gabbi api tests covers some fo those 15:35:10 like the basic stack/resource/template api stuff 15:36:53 OK, I just want to make sure we're not throwing away the stuff we will need for DefCore tests 15:37:25 no, I think they're fine with the list I porposed 15:38:50 We don't use them(now, after the job changes), there is just another tempest gate layer-4 job that uses those tests. 15:39:22 Not sure if anyone else uses it downstream, but that's tempest teams call, I suppose 15:40:33 there's a goal proposed (which not yet merge) on queen release about move all tests out of tempest repo 15:41:19 so we have to start considering to take those tests back to heat or do something else 15:41:22 ricolin: it's been proposed since a long time, not everyone agrees to it 15:42:10 ramishra, okey, than it might not be a good reason here:) 15:42:15 I doubt it would be accepted as a goal so easily, though anything can happen;) 15:43:30 ramishra, yep, not every team use tests in tempest like us! lol 15:44:31 #topic Open discussion 15:45:12 ramishra, about the define test https://review.openstack.org/#/c/454222 15:45:24 I had a question about Heat's plans for testing. I know you're removing Tempest tests, but I was wondering if you were only interested in having gabbi API tests. 15:45:28 ramishra, I'm still asking interop team 15:46:04 blancos you mean for heat API tests? 15:46:36 blancos: all of our integration tests run with heat tempest plugin(which is in heat tree) 15:46:51 I'm part of a QA project called Patrole that focuses on RBAC testing using a project's policy.json or policy in code. We had originally developed some tests for Heat for our Tempest plugin, but now that Tempest is moving away from that, we were wondering if your team might be interested. 15:48:33 blancos, If you using tempest, you can also use heat_integrationtests.api for our gabbi API test 15:49:33 blancos: Where does your tempest plugin live, in Patrole tree? 15:49:40 ricolin Right, the tests we have currently make use of the code in heat_integrationtests, but they're for testing policy enforcement instead of APIs 15:49:48 ramishra Yes, currently. 15:50:19 ramishra We have tests for Nova, Neutron, Keystone, Cinder, and Glance here https://github.com/openstack/patrole 15:50:23 #link https://github.com/openstack/patrole 15:52:15 blancos, we're considering to work a tempest plugin in heat which will keep use heat_integrationtests 15:52:38 blancos, but you already can run those test with tempest too 15:52:59 not sure it will help you? 15:53:33 ricolin We already have the tests developed, it's more that we're wondering if you're interested in giving them a home :) 15:53:50 We would maintain them 15:54:17 blancos, oh, I understand you just now! 15:54:18 blancos: so you're suggesting that we adopt https://github.com/openstack/patrole/tree/master/patrole_tempest_plugin/tests/api/orchestration in heat? 15:55:12 why don't you maintain them in your tree like you do now? 15:55:18 ramishra Those tests are currently out of date, but yes essentially 15:55:51 ramsihra We spoke to the QA of Tempest and they recommended we (as a plugin) not rely on the presence of other plugins (which is where Heat tests will be moving, as I understand it) 15:57:24 3 mins left 15:57:49 therve: you still around? 15:58:15 ramishra, I think we might need a BP for this? 15:58:40 blancos: oh, you're actually inheriting from the existing tests? 15:59:32 zaneb Sorry if I wasn't clear, but those tests are outdated. We started refactoring work, but put a hold on it for now 15:59:50 #link https://review.openstack.org/#/c/453348/ Here's the refactored tests 16:00:15 Okey, time's up one let's move back this discussion back to heat 16:00:48 one last thing here, we not doing meeting next week since it's Summit week 16:01:02 thx guys, back to heat 16:01:03 #endmeeting