13:00:14 #startmeeting heat 13:00:15 Meeting started Wed Dec 13 13:00:14 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:16 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:19 The meeting name has been set to 'heat' 13:00:21 #topic roll call 13:00:36 o/ 13:00:42 o/ 13:02:01 o/ 13:02:10 Hi 13:03:01 o/ 13:03:11 #topic adding items to agenda 13:03:21 #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282017-12-06_1300_UTC.29 13:04:10 hi 13:04:17 hi 13:04:55 ramishra, therve, I think our release note job is broken. this should fix it https://review.openstack.org/#/c/527672/ 13:05:54 OK I'll look 13:05:59 therve, thx 13:06:29 #topic categorize integration tests https://etherpad.openstack.org/p/heat-integration-test-categories 13:06:37 #link https://etherpad.openstack.org/p/heat-integration-test-categories 13:06:44 zaneb, around? 13:07:59 So zaneb helps to categorize tests 13:09:12 I had a look, the split looks ok. I assume we're planning to only keep the regression tests in tree? 13:10:21 I'm not sure the separate point 13:10:58 Though I felt some of the tests in that category would not have regressions 13:11:28 first three categorize seems like will move to plugin 13:11:45 ramishra, you mean test_cancel_update? 13:12:24 ricolin: I'm fine with zaneb's comment there 13:14:15 also agree with you that lbaasv1 can just removed 13:14:23 functional/test_create_update.py test_delete 13:14:39 unctional/test_delete.py 13:15:38 I'm not sure if those tests would have any regressions. But I'm ok with split 13:15:50 ramishra, seems it only delete a simple rg 13:17:02 we can comment and discuss that one in review 13:17:03 yeah, deleting CREATE_IN_PROGRESS stack 13:19:00 Can we just separate into two tempest plugin (in heat and in heat-tempest-plugin) and move the in repo one to other test way later(or keep use tempest) 13:19:42 No using tempest annoys people apparently 13:20:22 ricolin: we can't have an in-tree tempest plugin, that'll defeat the goal 13:21:00 therve ramishra , so I guess revert (or partially revert) https://review.openstack.org/#/c/348570/ first than 13:21:54 Probably more last 13:22:11 let's make the patch out these two days and start review 13:23:46 Any concerns or ideas before we start separate tests? 13:24:03 or warning 13:24:57 we would have to maintain common modules both in-tree and in heat-tempest-plugin, that can probably be problematic 13:25:38 they would diverge, but that may be ok I think 13:25:53 I think we can move all common to plugin? 13:26:53 and use plugin as a library for in-tree tests? Not sure I understand 13:27:10 I'm not sure that would work 13:27:15 ramishra, just like you said 13:28:32 ramishra, Why wouldn't that work? 13:29:11 you've to install the tempest-plugin when installing heat and that would again be the same problem, no? 13:30:24 Why? We won't run tempest 13:30:25 ramishra, IMO that only happens if we reference heat in common lib 13:30:41 The issue would be installing heat when you install the plugin, IIUC 13:31:43 what about moving the gate tests in a seperate folder in heat-tempest-plugin and keep tempest tests in heat-tempest-plugin and re-use it in the gates? 13:32:22 for example https://github.com/openstack/sahara-tests 13:32:24 the issue is when you install heat, if the tempest-plugin is installed(which would be the case when it's used in in-tree tests) and it would create problems for other plugins 13:33:14 unless the in-tree tests are in a separate package 13:35:38 if I'm not missing anything, that's the exact reason why we can't have in-tree tempest plugin 13:36:04 Not sure I fully understand that, but if we only use common libs in plugin that shouldn't lead to discover in-tree temest plugin 13:37:00 considering that we will remove in-tree tempest plugin 13:37:50 s/ discover in-tree temest plugin/ discover in-tree tests/ 13:38:49 Anyway, we can do separate tests first and discuss this later 13:38:51 ricolin: you would have heat-tempest-plugin in heat requirements and installing that would be add the entry point for tempest to discover https://github.com/openstack/heat-tempest-plugin/blob/master/setup.cfg#L31 13:42:39 ramishra, so the issue you thinking about is heat-tempest-plugin might be a unwanted plugin which forced installed when install heat? 13:44:07 ricolin: I'm not thinking about it, when heat is installed and then tempest is run it would discover heat-tempest-plugin, which user never wanted and would break other project tests 13:44:12 anyway, let's move on 13:44:28 we'll see when someone works on it:) 13:44:34 ramishra, yeah few more topics to go, let's discuss this later 13:44:46 #topic grenade-multinode 13:44:54 Hi o/ 13:45:10 Regarding grenade-multinode job, I have proposed a new patchset to add some additional tests. 13:45:16 #link https://review.openstack.org/#/c/510400/ 13:45:48 At this time, I have to list all tests in code. We could have an upgradetests file and port it to previous branch, probably. 13:45:58 Could you review this patch? I'm not pretty sure about the set of heat functional tests. 13:46:09 That's all from me, thanks. 13:46:38 kiennt26, so the issues we have is we're moving around tests right now so something like _write_heat_integrationtests in https://review.openstack.org/#/c/510400/59/devstack/upgrade/resources.sh might needs to change later 13:47:18 ricolin: yeah, I understand. 13:47:44 kiennt26, the patch looks good to me, but unfortunately might need to wait for the test migration jobs done:( 13:48:17 ricolin: it's ok, thank you :) 13:48:23 thx:) 13:48:36 kiennt26, move on? 13:48:55 ricolin: Yeah 13:48:59 #topic CI status 13:49:53 anyone like to host this?:) 13:50:23 CI failure a lot for this few weeks:( 13:51:04 ricolin: Many of those are due to zuul issues and tests using fedora image. 13:51:15 ramishra, this seems works https://review.openstack.org/#/c/527358 13:51:30 It would probably be better to take stock of it after the zuul issues are resolved? 13:52:43 ricolin: I would probably not change m1.heat_micro flavor 13:53:30 it's used with all tests using cirros image, we 're unnecessarliy increasing the memory usage 13:53:53 heat_int is the main one we use for failed tests 13:54:18 If we think flavor memory capacity is an issue, we should use different flavor in the failing tests 13:54:58 I like the idea therve thinking about, to use default devstack flavor 13:55:41 s/thinking/thought/ 13:56:07 I don't know the history on why we don't use devstack standard flavors 13:56:25 maybe zaneb knows why:) 13:56:31 will ask him later:) 13:57:06 4mins left, move to next 13:57:09 #topic Octavia support 13:57:32 So we have this bug 13:57:40 https://bugs.launchpad.net/heat/+bug/1737567 13:57:41 Launchpad bug 1737567 in OpenStack Heat "Direct support for Octavia LBaaS API" [Medium,New] 13:57:46 ok, someone added the topic, I thought we would discuss next meeting:) 13:57:51 I did 13:58:23 Regardless of how bad it is to create another API 13:58:39 I'm in favor of creating new resources 13:58:40 I've added some comments there, it seems there are some issues with neutron-lbaas 13:59:23 so the suggestion is to use different api calls based on the 'provider' property. But I think there would be issues when you change the provider 13:59:32 Yeah I don't like this idea 13:59:41 some objects would be in neutron-lbaas and some in octavia 13:59:42 Just add new resources 14:00:03 therve: I've the patches to do that, I'll post them soon 14:00:11 ramishra, OK cool 14:00:14 That's all then :) 14:00:40 how about original neutron lbaas resource 14:01:00 deprecate it? 14:01:09 At some point yeah 14:01:10 deprecate;) we've been doing that with lbaas all the time. 14:01:27 cool 14:02:04 but the issue, till the octavia has the support for all drivers we can't depecate the lbaasv2 resources 14:02:17 Why 14:02:32 We don't have to support things neutron doesn't 14:03:27 Also we don't have to hurry to deprecate it, it doesn't really matter 14:03:29 yeah, when neutron-lbaas is not supported, but I've been hearing that probably for some time 14:03:43 the api extension is not deprecated yet 14:04:34 we can consider to deprecate it after neutron-lbaas does 14:05:09 without proper support for existing drivers, I don't know how they would deprecate 14:05:31 Maybe it won't happen 14:05:32 It seem the driver spec for octavia is still in discussion 14:06:33 ramishra, any target schedule for that so far? 14:07:17 I'll do that this cycle.. may be queens-3? 14:07:34 got it 14:07:40 we already 7mins pass our time 14:07:53 anything to discuss? 14:08:49 Okay, thanks all for join! let's end it 14:08:52 #endmeeting