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