13:00:22 #startmeeting heat 13:00:23 Meeting started Wed Dec 6 13:00:22 2017 UTC and is due to finish in 60 minutes. The chair is ricolin. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:24 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:26 The meeting name has been set to 'heat' 13:00:30 #topic roll call 13:01:05 hi 13:01:10 o/ 13:01:23 zaneb, therve meeting time:) 13:01:44 o/ 13:01:51 o/ 13:03:03 kazsh, what you mean by topic -> temporarlly remove admin panel for Heat (heat-dashboard 13:03:49 ricolin: current horizon has admin panel for heat apart from orchestration panel group 13:04:12 oh okay got it 13:04:21 #topic adding items to agenda 13:04:27 #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282017-12-06_1300_UTC.29 13:05:20 maybe 8:00 is too early US-East 13:05:54 * ricolin never understand the light saving time changes 13:05:59 ricolin: not many around to discuss some important topics 13:06:11 may be we postpone them to next week 13:06:17 ramishra, we can do others first 13:06:26 o/ 13:06:38 zaneb, good morning!:) 13:07:52 we could talk about the tempest goal 13:08:35 zaneb, on the topics:) 13:08:48 let's do that one first 13:08:48 so it is :) 13:08:53 #topic heat tempest plugin 13:09:42 so there's been some interesting discussion on https://review.openstack.org/#/c/521602/ 13:09:54 I'd encourage everyone to go read that 13:10:37 but the way it's shaping up is it looks like any stuff we leave in-tree should just not be a tempest plugin 13:11:12 we can meet the goal just by removing the endpoint from setup.cfg 13:12:03 didn't ready in that review yet, but can't we said that in tree plugin just for CI usage? 13:12:17 what we'll need is some way of running the tests from two different sources (plugin repo plus in-tree) in the gate 13:12:38 I was looking at how many functional tests we've changed in the last six months for any code changes, they are very very few 13:12:58 it's mostly adding tests for existing functionality or new tests 13:13:48 ricolin: yes, but it can't have a tempest plugin endpoint in setup.cfg. that's what breaks other projects just by having heat installed if we break test discovery 13:14:24 so a mechanism for running the two lots of tests together is still under discussion 13:14:38 and we'll also need to decide which tests belong where 13:15:14 probably more should go to the plugin than I originally thought 13:15:44 because there are several use cases for tempest other than interop 13:16:11 zaneb, so if we all agree some tests to go to plugin, that means those test in long term should be branchless, right? 13:16:32 e.g. co-gating, running against clouds to check that they're configured correctly 13:17:32 ricolin: tbh I'm not completely convinced that all of those use cases want branchless tests. but we might just have to live with that 13:18:01 Merged openstack/heat-dashboard master: Align tox_install.sh with other projects https://review.openstack.org/524136 13:18:03 anything that is purely testing regression stuff in Heat should stay behind IMO 13:18:26 totally agree with that 13:18:58 anything with an integration component should _probably_ move to the plugin 13:19:23 I guess I need to make a list, don't I 13:20:32 what you mean by integration component 13:20:59 I mean it's testing interaction with some other service 13:22:09 zaneb: Now that we've created the new repo, we can just see how many tests are creating issues and then move them as we go from the new repo, or as u said we can leave all tests in-tree for now, but we've to manage the changes in both repos. 13:23:11 or may be if we outrightly can identify what tests to have in-tree and how we test them 13:24:19 ramishra: I'd rather try to identify them ahead of time if possible, so that we don't delete them and lose the git history 13:25:28 my only concern is managing changes. 13:25:43 ramishra: hello 13:25:44 yeah, we are in limbo at the moment 13:25:50 with code in two places 13:26:18 for managing changes you can use depends-on in gerrit reviews 13:26:19 chandankumar: hi 13:26:28 ramishra: we're currently running the tests from the plugin not the repo, is that right? 13:26:43 zaneb, yes 13:26:59 yeah from the external plugin repo not in-tree tests 13:27:37 yes, that's what I meant :) 13:27:46 * zaneb was extremely ambiguous 13:27:56 ok, so rough plan 13:28:07 1) identify tests we can safely delete from the heat tree 13:28:20 2) find a way of running tests from both sources 13:28:38 3) delete tests that are staying behind from the plugin repo 13:29:15 meanwhile try to avoid landing changes in only one place, I guess 13:29:47 is there any problem with branchless nature of plugin? 13:30:16 we've to keep a close watch on patches that modify tests, I can see a few around which make changes to tests in-tree. 13:30:19 Is it possible that keep common test utils in plugin for tests from both sides? 13:30:54 ricolin: yes. that's probably a good idea 13:31:11 * zaneb hadn't thought about that 13:31:56 that's something after (3) I guess 13:32:33 ramishra, what you think about zaneb's plan 13:33:15 ricolin: yeah, if we can do 1 & 2 quickly, we'll avoid the mess we're in 13:33:48 zaneb, how you suggest we start on doing (1) 13:34:03 but till we do that we would probably have a hard time landing patches that change tests 13:34:21 * zaneb reluctantly volunteers to take an #action 13:35:40 ramishra: agree. unfortunately 1 & 2 are the hard ones. 3 is easy 13:35:53 well, 1 isn't _hard_. it's just work 13:36:43 zaneb, we absolutely needs you to in part for 1:) 13:37:28 #link https://etherpad.openstack.org/p/heat-integration-test-categories 13:37:36 #action zaneb will help on identify tests we can safely delete from the heat tree 13:37:37 I'll start in there 13:38:20 for 2 may be we can probably run the tests without tempest, that means revert to the way we tested before we moved to use tempest plugin 13:39:12 ramishra, yeah, if we can't have a extra plugin for heat CI 13:39:35 ricolin: "extra_plugin"? 13:40:21 AFAIU, it would not be a tempest plugin 13:40:23 ramishra: so the trick will be that we want to discover the tests from the plugin and the tests from the local repo and run them all together using the same unittest run 13:40:37 I mean like second tempest plugin, but it seems any tempest plugin in tree will not happen:) 13:41:08 but yeah, it may just be a case of doing everything the old way and not treating the tempest plugin as a tempest plugin in our gate 13:41:51 zaneb, ramishra any concerns or issues when we not using tempest plugin? 13:41:58 ricolin: I like the idea of splitting the plugin mechanism out of tempest, so that we can do test suite plugins without interfering with tempest. that was discussed in the review I linked earlier. we'll see where it goes 13:42:33 zaneb, thanks will read that right after meeting 13:42:34 we can run them separately at the gate plugin tempest tempest tests + in-tree tests with 'tox -eintegration' 13:42:38 ricolin: nope. it appears the plugin mechanism is literally just 50 lines of code that does test discovery 13:43:27 we can still use tempest-lib stuff from the tempest tree. so really no concerns about how a non-plugin would work 13:43:58 just a shame we can't use that handy plugin mechanism any more at the moment 13:45:03 #link https://review.openstack.org/#/c/521602/ 13:45:14 for the minutes ^ :) 13:46:21 so we revert first and see if we like to use tempest-lib further for discover? 13:48:28 we don't use tempest-lib stuff I think 13:48:48 tempest-lib isn't for discovery 13:49:15 we use python*_clients 13:49:31 we just use tempest as the test runner 13:52:14 we're on this one topic for the whole time it seems:) 13:52:17 ramishra: I just got schooled about that :) according to tempest folks, tempest is just a test suite and the testrunning is unvarnished unittest/testr 13:54:36 zaneb: OK, I think I somewhat understood that though 13:56:00 sounds like our original design:) 13:56:11 pretty much 13:56:33 we can definitely move to another topic now if folks want to 13:57:05 we might still needs a action here I think:) 13:57:08 we did not have the test discovery (with plugin) part though 13:57:43 yeah, and that's the part we will need to figure out 13:58:17 we still have few topic to go:( 13:58:44 I propose we extend this meeting 13:58:52 +1 13:59:06 ricolin: I've to leave in 5 mins 13:59:14 ramishra, NP 13:59:44 anyway that's do this quick 14:00:02 we leave rest topic to next 14:00:10 ramishra: which topic would you most like to discuss in the next 5 minutes? :) 14:00:46 zaneb: I've not added anything to the agenda:) 14:01:04 maybe we go with kazsh's one? 14:01:10 thx! 14:01:15 +1 14:01:29 #topic temporarlly remove admin panel for Heat (heat-dashboard 14:01:42 heat-dashboard is almost ready for queens-2 14:02:04 \o/ 14:02:15 kazsh, I will release rest heat to queens-2 today 14:02:16 resolved points horizon guys commented 14:02:26 ricolin: thx! 14:02:41 and 14:02:43 kazsh, is it possible we release heat-dashboard before Friday? 14:03:03 ricolin: yep! it's ok even now :) 14:03:12 but only one thing 14:03:21 I wanna consult with you 14:03:38 as you might know, current horizon has admin func for heat 14:03:54 just displaying the result of "openstack orchestration service list" 14:04:02 the list of engine services 14:05:13 migrate this func is tricky because the code is not in orchestration panel group's code 14:05:35 something tightly coupling with other code 14:05:51 so where these code are right now? 14:06:12 https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/admin/info/tables.py#L256 14:06:16 around here 14:06:25 kazsh: if that's all it does then I wouldn't worry about it 14:06:41 bye guys, got to go, will check the meeting notes later 14:06:51 zaneb: thx I'm on same page as you 14:06:52 ramishra: thanks o/ 14:06:57 ramishra, bye! thanks for your attend! 14:07:15 horizon guy also has same thought 14:07:31 kazsh, any plan after this temporary removal? 14:07:33 as heat team, is there any objection on this approach ? 14:07:36 well 14:07:59 kazsh, I have no objection on that:) 14:08:06 no objection from me 14:08:10 one of them is saying we should talk about make admin panels as a plugin 14:08:16 prob..next PTG ? 14:08:38 along with heat-dashboard code, horizon team is preparing this chage https://review.openstack.org/#/c/523402/ 14:08:48 trying to split out all of heat support from horizon repo 14:08:59 already got one +2 from the core 14:09:13 zaneb: thx:) 14:09:29 horizon team is waiting for our answer on this 14:09:33 we can always have a PTG session for this 14:09:59 ricolin: yep:) 14:10:30 we can drop it once we release heat-dashboard queens-2 IMO 14:10:54 yep, the current heat-dashboard code does not have any admin func 14:11:11 and i a few days, 523402 will be merged in horizon side 14:11:42 ok I got a couple of +2 from heat core :) 14:11:58 so final ask It's fine for me to release heat-dashboard now? 14:12:13 ricolin: yes :) 14:12:14 in my experience, at least, ~nobody uses the GUI for admin stuff 14:12:24 zaneb: +1 14:12:34 zaneb, bloody true 14:12:59 well I will inform our decision to Horizon team 14:13:06 kazsh, thanks 14:13:26 thanks ricolin, zaneb :) 14:13:52 Rabi is away now, I guess we can leave rest for next week:) 14:14:04 14mins ahead:) 14:14:32 #action rico will release heat today 14:14:52 thanks you for join:) 14:15:08 if no question let's end it 14:15:17 +1 14:15:45 #endmeeting no sounds means no question:)