20:00:02 #startmeeting Octavia 20:00:03 Meeting started Wed Jan 24 20:00:02 2018 UTC and is due to finish in 60 minutes. The chair is johnsom. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:04 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:07 The meeting name has been set to 'octavia' 20:00:13 Hi folks 20:00:20 hi 20:00:20 hi 20:00:21 hi guys 20:00:25 #topic Announcements 20:00:26 hi 20:00:45 We are officially in feature freeze for Queens 20:00:58 Our MS3 patch is working through the gates 20:01:15 It was a bit delayed (as usually happens) due to the gates being broken/backed up 20:01:26 which patch is it ? 20:01:35 But no worries, it will go out on time 20:01:43 #link https://review.openstack.org/537605 20:01:54 tnx 20:02:59 xgerman_ rm_work nmagnezi Cores: This means no +A workflow for patches that contain features until we have our Queens release out. 20:03:14 k 20:03:51 Also a note, the gates are really backed up right now, so if you can delay posting patches that are non-critical, it might help with the congestion. 20:04:11 Evidently they lost some testing hosts which is not helping. 20:04:28 It should clear up Friday 20:04:29 ;-( 20:04:34 =/ 20:04:36 Merged openstack/octavia master: Updated from global requirements https://review.openstack.org/533913 20:05:10 I will continue to maintain our priority bug list: 20:05:15 #link https://etherpad.openstack.org/p/Octavia-Queens-Priority-Review 20:05:42 But the focus will shift to bug fixes, docs updates, release notes updates, etc. All the stuff we need for our release candidate. 20:06:01 Also, just a reminder: PTL nominations for Rocky open January 29th 20:06:08 #link https://governance.openstack.org/election/ 20:06:14 In case you are interested in running 20:06:54 Another important announcement, cross repository dependencies are changing in Zuulv3. 20:07:02 #link http://lists.openstack.org/pipermail/openstack-dev/2018-January/126535.html 20:07:15 It will now use the URL to the patch as opposed to the commit ID 20:07:42 not commit ID but Change-Id :) 20:08:18 Finally, we are lobbying for the next LTS Ubuntu release to include HAProxy 1.8-stable. Please vote on the bug if you would like to see that as well: 20:08:25 #link https://bugs.launchpad.net/bugs/1743465 20:08:25 Launchpad bug 1743465 in haproxy (Ubuntu) "Bionic should have haproxy 1.8-stable" [Undecided,Confirmed] 20:08:44 cgoncalves_ Ha, yeah, that... Don't do that anymore. grin 20:08:46 agreed, just voted 20:09:26 me too 20:09:36 That will bring some attention to the bug. I see that Ryan has already set it up for Fedora, so likely in the chain for the RH type distros. 20:10:08 Any other announcements today? 20:10:45 #topic Brief progress reports / bugs needing review 20:11:45 I have been working on the OVS integration into our amphora image and coming up to speed on Ryu. Otherwise it has been all things milestone 3 release(reviews, babysitting the gates, etc.) 20:12:16 Any other updates of note? 20:12:26 could u expand the meaning of that ? 20:12:31 ovs in the amphora 20:12:46 yes. the health monitor vif init 20:13:09 (sorry, typing on a different keyboard and layout tonight) 20:13:47 Sure, one of the proposed Active/Active drivers uses OVS / OpenFlow as the front end distributor. The current patches proposed by an IBM team are posted, but they need work and I have adopted those to move them forward. 20:13:53 I submitted to gerrit the code (very WIP). hopefully it will give people an idea of whats being proposed 20:14:03 which part are you using ryu for? 20:14:04 This requires a semi-recent version of OVS to be included in our amphora image. 20:14:43 johnsom, ohh this is the next level of octavia, the distributor stuff. I only saw it in docs and presentations till now 20:14:58 is it to soon to learn this architecture ? 20:15:24 I am just getting up to speed on Ryu, so I can't comment deeply. The IBM patches use command line uglyness to do the OpenFlow configuration. I don't like that as we know member add/remove is high volume with the container crowds, so I'm looking to use Ryu like neutron does. 20:15:52 well, members would git the haproxy 20:15:58 not the dustributor 20:16:05 It's pretty early still and non-functional at this point 20:16:36 Oh, yeah, right, sorry, I was mentally thinking of elastic scale, but translated to members. 20:17:59 You can read through the old patches, just be aware they will not merge as-is, there is a bunch of work to do in cleaning them up. So far I'm three patches into that process. 20:18:32 yeah, took a stab earlier they have gotten real stale over the years 20:18:52 cgoncalves_ Do you want to put links in the minutes, or at a later meeting? 20:19:35 johnsom: let me get it (not on my computer now) 20:19:48 Ok, I will move on then since we have a long agenda 20:19:56 #topic Deprecation start for neutron-lbaas 20:20:04 Ok, the big discussion 20:20:15 #link https://review.openstack.org/#/c/536613/ 20:20:26 We are at the end of Queens and need to make the call on starting the deprecation cycle for neutron-lbaas. 20:21:05 As a reminder, this does not mean the code is archived, the project removed, or that it goes unsupported. We follow the OpenStack standard deprecation process. 20:21:12 +1 20:21:17 +1 for deprecation 20:21:29 +1 20:21:30 #link https://governance.openstack.org/tc/reference/tags/assert_follows-standard-deprecation.html 20:22:06 OSP13 will deprecate neutron-lbaas and fully support octavia 20:22:15 It means that we halt all feature patches, encourage folks to start planning/using Octavia, etc. 20:22:25 yep 20:22:26 that puts us in a bind to hammer out the providers in R… 20:22:38 We, as the LBaaS community will still need to support bug fixes until the deprecation clock ends. 20:22:55 cgoncalves_ What is OSP13? 20:23:07 johnsom, queens 20:23:11 johnsom: red hat openstack platform 13 (queens based) 20:23:22 Ok, cool 20:23:36 The only way I can support this is that we have merged the driver spec. 20:24:00 right 20:24:18 We also do not have to set a hard EOL date at this time. Minimum is two cycles, but we may go three to make sure we get drivers moved over. 20:24:53 I would like to propose a vote on neutron-lbaas deprecation. 20:25:19 #vote Should we officially announce the neutron-lbaas deprecation cycle is starting in Queens? 20:25:26 johnsom: better do it offline via email, no? 20:25:36 #startvote Should we officially announce the neutron-lbaas deprecation cycle is starting in Queens? 20:25:37 Begin voting on: Should we officially announce the neutron-lbaas deprecation cycle is starting in Queens? Valid vote options are Yes, No. 20:25:38 Vote using '#vote OPTION'. Only your last vote counts. 20:25:48 #vote Yes 20:25:53 #vote Yes 20:25:57 #vote Yes 20:26:01 #vote Yes 20:26:02 #vote Yes 20:26:04 #vote yes 20:26:26 cgoncalves_ We don't usually vote on such things via e-mail, plus I would like an initial vote here to gauge where we are at. 20:26:53 yeah, we do either what here or with the online voting service 20:26:57 Any other voters? 20:27:09 Going once 20:27:10 \what\vote 20:27:18 johnsom: ok. I just suggested that because many cores are not attending the meeting now :) 20:27:26 Going twice 20:27:34 Well, we have 50% of the cores... 20:27:50 rm_work want to vote? 20:27:51 ah! :D 20:27:58 uhhhh 20:27:58 hey 20:28:15 I believe nmagnezi would also vote in favor of it ;) 20:28:42 #vote Yes 20:28:43 Yeah, I'm pretty sure too 20:28:43 #vote Yes 20:28:43 #vote Yes 20:28:44 #vote Yes 20:28:53 only last counts 20:28:53 only last vote counts 20:28:54 :P 20:29:01 Ha, ballet stuffer. 20:29:02 haha 20:29:05 xgerman_++ 20:29:13 #endvote 20:29:14 Voted on "Should we officially announce the neutron-lbaas deprecation cycle is starting in Queens?" Results are 20:29:38 Ummm 20:29:45 bad bot 20:30:15 #endvote 20:30:23 #showvote 20:30:33 Ha, well, ok, we have the logs 20:30:34 I think I only saw yes 20:31:09 I guess since Doug left we haven't been exercising the vote bot enough. 20:31:19 yeah, we're good with the logs 20:31:40 dougwig? 20:31:47 unless the bot also decides not to cooperate 20:32:08 maybe the bot says no ? 20:32:12 he has the power 20:32:17 That is a good indicator that I should start moving forward with this. I will put together an email to the dev and ops lists and then start putting up patches to mark neutron-lbaas and neutron-lbaas-dashboard as deprecated. 20:32:50 #topic CLI for driver specific features 20:32:57 #link https://etherpad.openstack.org/p/octavia-drivers-osc 20:33:27 Last week we setup an etherpad to put together ideas of how to handle the driver specific commands. 20:33:41 xgerman_: ack 20:33:54 missed the vote 20:34:10 haha 20:34:16 dougwig Hi, we were just commenting about the vote bot not working on our deprecate neutron-lbaas vote. We haven't used it enough since you left. 20:34:46 because there is no more contention? :) 20:34:54 Are there any more comments on the OSC CLI for drivers? 20:34:59 It's all unicorns and rainbows here 20:35:04 dougwig true, it was unanimous 20:35:11 Everyone agrees all the time on everything :P 20:35:30 that happened after sbalukoff left ;-) 20:35:37 lol 20:36:37 Ok, so there are four proposals on the etherpad. I think we should each enter our IRC nics in for the colors in etherpad and +1 the option we prefer. Voting for more that one is fine. 20:37:00 It's a bummer we didn't come up with any examples from other projects. 20:37:45 :-( 20:37:56 sorry, I was the one proposing checking other projects. I didnt have time this week 20:38:45 I think that when an operator create load balancer or loadbalancing related stuff we have to have loadbalancer in line 20:38:58 I kind of like being more explicit 20:39:02 Please vote, the top vote(s) I will take and check in with the OSC team to make sure they are on board and we can move forward on the patch that is proposed. 20:39:11 and if we look on other loadbalancer stuff it is loadbalancer pool, listener , health monitor , etc 20:39:19 honestly I would consider renaming the octavia driver to something different even. having the project and the driver with the same name is confusing 20:39:29 +! 20:39:52 xgerman_: is that a yes or a no? :) 20:39:58 yes 20:40:04 It is a bit confusing, but since it's the reference driver it kind of has precedent and makes sense. 20:40:15 * xgerman_ starts watching Top Gear for appropriate car model names 20:40:25 lol 20:40:40 xgerman_: skip the review of skoda octavia please :P 20:40:43 If we are serious about renaming it, we should consider moving it out to it's own driver repo. (which isn't a bad idea) 20:41:02 lol 20:41:36 Ok, please vote. I am going to move on to the next topic 20:41:37 yeah, I think we should pick that up as the whole provider driver refactor/rework 20:41:54 are we ever going to have other drive specific cli options? 20:41:54 #topic Octavia testing planning 20:42:06 #link https://etherpad.openstack.org/p/octavia-testing-planning 20:42:10 if that is the case I think it is important to have driver in name 20:42:12 yoohooo 20:42:54 jniesz Good question, but I would guess so. Given the OSC plugin model, there is really no reason driver providers could not add additional admin commands 20:43:28 Ok, all things test planning 20:43:52 I was not able to find the link to the old test plan google doc. 20:44:07 Actually, fnaval might still have it if he is arround 20:44:49 hi - I don't think I ever had a testplan for Octavia 20:44:56 Alex_Staf I see you have a questions block. Is this something we should answer for each type of test listed above? 20:44:58 but I think I had one for neutron lbaas 20:45:08 ok so I have written a plan but it is scenario only test , with traffic and HA . 20:45:10 yep, same thing 20:45:16 nope , it is general questions 20:45:18 fnaval Yeah, we had a google doc spreadsheet with a test matrix/plan 20:45:42 fnaval If you happen to still have a link around... 20:45:47 checking 20:46:27 Thx 20:46:30 Ok, so on unit testing, I think that is pretty clear (correct me if not). It is code - method level testing, typically with mocking. 20:47:38 functional is where Octavia is "weird". 20:48:02 We have functional tests that run against live DB and API without a full devstack running. 20:48:18 This is good as they are fast. 20:48:32 https://docs.google.com/spreadsheets/d/1MxAAQ33rS4iH4ekwsW8DnZyKxi7oE4TZeHvJcM6STyY/edit?usp=sharing 20:48:34 https://docs.google.com/spreadsheets/d/1EBIwBEL5Tyzc2nU_05uqCRP5mjEvZAlhdmzhKjQl8sg/edit?usp=sharing 20:48:38 Down side is they are in-tree, so are branch specific 20:48:48 thanks fnaval 20:49:13 yep 20:49:16 Ah, the second one is not right 20:49:47 that probably is the internal implementation 20:50:23 #link https://docs.google.com/spreadsheets/d/1MxAAQ33rS4iH4ekwsW8DnZyKxi7oE4TZeHvJcM6STyY/edit?usp=sharing 20:50:30 That is what we were looking for 20:50:34 kk 20:52:02 The question I have about our current functional is it overlaps with what is typically done with tempest API tests 20:52:19 Do we need/want both? 20:52:47 we have functional ? I mean automated 20:53:09 Alex_Staf Yes 20:53:23 #link https://github.com/openstack/octavia/tree/master/octavia/tests/functional 20:54:06 #link http://logs.openstack.org/38/521138/21/check/openstack-tox-functional/5857e19/testr_results.html.gz 20:54:18 I think if it overlaps API only is ok 20:54:34 I think they are useful to have in tree and would be sad if they're gone 20:55:15 These are DB and API tests that run without devstack. For DB it runs an in-memory DB, for the API it uses the framework test suite and noop drivers. 20:57:08 Alex_Staf not sure I follow your comment. 20:57:19 which one ? 20:57:30 The overlaps one 20:58:12 ignore missread your question regarding API and functional overlapping 20:58:19 We are about out of time, bummer. 20:58:41 Maybe we can fill this in a bit more and pick it up as the first topic next week. 20:58:50 ok so I wil ltry to use what we have in API functions to write more complex tests. 20:59:28 We have basic functions for for LB objects creation , I will try to work with that 20:59:31 The functionals are intended to only test the API and DB calls. It is not a scenario or set of "live" commands 21:00:07 Let me try to write up more in the etherpad for next week. 21:00:16 #endmeeting