20:00:02 <johnsom> #startmeeting Octavia
20:00:03 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:07 <openstack> The meeting name has been set to 'octavia'
20:00:13 <johnsom> Hi folks
20:00:20 <longstaff> hi
20:00:20 <xgerman_> hi
20:00:21 <Alex_Staf> hi guys
20:00:25 <johnsom> #topic Announcements
20:00:26 <cgoncalves_> hi
20:00:45 <johnsom> We are officially in feature freeze for Queens
20:00:58 <johnsom> Our MS3 patch is working through the gates
20:01:15 <johnsom> It was a bit delayed (as usually happens) due to the gates being broken/backed up
20:01:26 <Alex_Staf> which patch is it ?
20:01:35 <johnsom> But no worries, it will go out on time
20:01:43 <johnsom> #link https://review.openstack.org/537605
20:01:54 <Alex_Staf> tnx
20:02:59 <johnsom> 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 <xgerman_> k
20:03:51 <johnsom> 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 <johnsom> Evidently they lost some testing hosts which is not helping.
20:04:28 <johnsom> It should clear up Friday
20:04:29 <xgerman_> ;-(
20:04:34 <Alex_Staf> =/
20:04:36 <openstackgerrit> Merged openstack/octavia master: Updated from global requirements  https://review.openstack.org/533913
20:05:10 <johnsom> I will continue to maintain our priority bug list:
20:05:15 <johnsom> #link https://etherpad.openstack.org/p/Octavia-Queens-Priority-Review
20:05:42 <johnsom> 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 <johnsom> Also, just a reminder: PTL nominations for Rocky open January 29th
20:06:08 <johnsom> #link https://governance.openstack.org/election/
20:06:14 <johnsom> In case you are interested in running
20:06:54 <johnsom> Another important announcement, cross repository dependencies are changing in Zuulv3.
20:07:02 <johnsom> #link http://lists.openstack.org/pipermail/openstack-dev/2018-January/126535.html
20:07:15 <johnsom> It will now use the URL to the patch as opposed to the commit ID
20:07:42 <cgoncalves_> not commit ID but Change-Id :)
20:08:18 <johnsom> 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 <johnsom> #link https://bugs.launchpad.net/bugs/1743465
20:08:25 <openstack> Launchpad bug 1743465 in haproxy (Ubuntu) "Bionic should have haproxy 1.8-stable" [Undecided,Confirmed]
20:08:44 <johnsom> cgoncalves_ Ha, yeah, that...  Don't do that anymore.  grin
20:08:46 <jniesz> agreed, just voted
20:09:26 <Alex_Staf> me too
20:09:36 <johnsom> 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 <johnsom> Any other announcements today?
20:10:45 <johnsom> #topic Brief progress reports / bugs needing review
20:11:45 <johnsom> 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 <johnsom> Any other updates of note?
20:12:26 <Alex_Staf> could u expand the meaning of that ?
20:12:31 <Alex_Staf> ovs in the amphora
20:12:46 <cgoncalves_> yes. the health monitor vif init
20:13:09 <cgoncalves_> (sorry, typing on a different keyboard and layout tonight)
20:13:47 <johnsom> 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 <cgoncalves_> I submitted to gerrit the code (very WIP). hopefully it will give people an idea of whats being proposed
20:14:03 <jniesz> which part are you using ryu for?
20:14:04 <johnsom> This requires a semi-recent version of OVS to be included in our amphora image.
20:14:43 <Alex_Staf> 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 <Alex_Staf> is it to soon to learn this architecture ?
20:15:24 <johnsom> 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 <xgerman_> well, members would git the haproxy
20:15:58 <xgerman_> not the dustributor
20:16:05 <johnsom> It's pretty early still and non-functional at this point
20:16:36 <johnsom> Oh, yeah, right, sorry, I was mentally thinking of elastic scale, but translated to members.
20:17:59 <johnsom> 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 <xgerman_> yeah, took a stab earlier they have gotten real stale over the years
20:18:52 <johnsom> cgoncalves_ Do you want to put links in the minutes, or at a later meeting?
20:19:35 <cgoncalves_> johnsom: let me get it (not on my computer now)
20:19:48 <johnsom> Ok, I will move on then since we have a long agenda
20:19:56 <johnsom> #topic Deprecation start for neutron-lbaas
20:20:04 <johnsom> Ok, the big discussion
20:20:15 <cgoncalves_> #link https://review.openstack.org/#/c/536613/
20:20:26 <johnsom> We are at the end of Queens and need to make the call on starting the deprecation cycle for neutron-lbaas.
20:21:05 <johnsom> 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 <xgerman_> +1
20:21:17 <cgoncalves_> +1 for deprecation
20:21:29 <longstaff> +1
20:21:30 <johnsom> #link  https://governance.openstack.org/tc/reference/tags/assert_follows-standard-deprecation.html
20:22:06 <cgoncalves_> OSP13 will deprecate neutron-lbaas and fully support octavia
20:22:15 <johnsom> It means that we halt all feature patches, encourage folks to start planning/using Octavia, etc.
20:22:25 <Alex_Staf> yep
20:22:26 <xgerman_> that puts us in a bind to hammer out the providers in R…
20:22:38 <johnsom> We, as the LBaaS community will still need to support bug fixes until the deprecation clock ends.
20:22:55 <johnsom> cgoncalves_ What is OSP13?
20:23:07 <Alex_Staf> johnsom, queens
20:23:11 <cgoncalves_> johnsom: red hat openstack platform 13 (queens based)
20:23:22 <johnsom> Ok, cool
20:23:36 <johnsom> The only way I can support this is that we have merged the driver spec.
20:24:00 <cgoncalves_> right
20:24:18 <johnsom> 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 <johnsom> I would like to propose a vote on neutron-lbaas deprecation.
20:25:19 <johnsom> #vote Should we officially announce the neutron-lbaas deprecation cycle is starting in Queens?
20:25:26 <cgoncalves_> johnsom: better do it offline via email, no?
20:25:36 <johnsom> #startvote Should we officially announce the neutron-lbaas deprecation cycle is starting in Queens?
20:25:37 <openstack> 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 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:25:48 <johnsom> #vote Yes
20:25:53 <xgerman_> #vote Yes
20:25:57 <cgoncalves_> #vote Yes
20:26:01 <longstaff> #vote Yes
20:26:02 <jniesz> #vote Yes
20:26:04 <Alex_Staf> #vote yes
20:26:26 <johnsom> 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 <xgerman_> yeah, we do either what here or with the online voting service
20:26:57 <johnsom> Any other voters?
20:27:09 <johnsom> Going once
20:27:10 <xgerman_> \what\vote
20:27:18 <cgoncalves_> johnsom: ok. I just suggested that because many cores are not attending the meeting now :)
20:27:26 <johnsom> Going twice
20:27:34 <johnsom> Well, we have 50% of the cores...
20:27:50 <johnsom> rm_work want to vote?
20:27:51 <cgoncalves_> ah! :D
20:27:58 <rm_work> uhhhh
20:27:58 <rm_work> hey
20:28:15 <cgoncalves_> I believe nmagnezi would also vote in favor of it ;)
20:28:42 <rm_work> #vote Yes
20:28:43 <johnsom> Yeah, I'm pretty sure too
20:28:43 <rm_work> #vote Yes
20:28:43 <rm_work> #vote Yes
20:28:44 <rm_work> #vote Yes
20:28:53 <Alex_Staf> only last counts
20:28:53 <xgerman_> only last vote counts
20:28:54 <Alex_Staf> :P
20:29:01 <johnsom> Ha, ballet stuffer.
20:29:02 <Alex_Staf> haha
20:29:05 <Alex_Staf> xgerman_++
20:29:13 <johnsom> #endvote
20:29:14 <openstack> Voted on "Should we officially announce the neutron-lbaas deprecation cycle is starting in Queens?" Results are
20:29:38 <johnsom> Ummm
20:29:45 <johnsom> bad bot
20:30:15 <johnsom> #endvote
20:30:23 <johnsom> #showvote
20:30:33 <johnsom> Ha, well, ok, we have the logs
20:30:34 <xgerman_> I think I only saw yes
20:31:09 <johnsom> I guess since Doug left we haven't been exercising the vote bot enough.
20:31:19 <cgoncalves_> yeah, we're good with the logs
20:31:40 <xgerman_> dougwig?
20:31:47 <cgoncalves_> unless the bot also decides not to cooperate
20:32:08 <Alex_Staf> maybe the bot says no ?
20:32:12 <Alex_Staf> he has the power
20:32:17 <johnsom> 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 <johnsom> #topic CLI for driver specific features
20:32:57 <johnsom> #link https://etherpad.openstack.org/p/octavia-drivers-osc
20:33:27 <johnsom> Last week we setup an etherpad to put together ideas of how to handle the driver specific commands.
20:33:41 <dougwig> xgerman_: ack
20:33:54 <xgerman_> missed the vote
20:34:10 <dougwig> haha
20:34:16 <johnsom> 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 <dougwig> because there is no more contention?  :)
20:34:54 <johnsom> Are there any more comments on the OSC CLI for drivers?
20:34:59 <rm_mobile> It's all unicorns and rainbows here
20:35:04 <johnsom> dougwig true, it was unanimous
20:35:11 <rm_mobile> Everyone agrees all the time on everything :P
20:35:30 <xgerman_> that happened after sbalukoff left ;-)
20:35:37 <johnsom> lol
20:36:37 <johnsom> 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 <johnsom> It's a bummer we didn't come up with any examples from other projects.
20:37:45 <xgerman_> :-(
20:37:56 <cgoncalves_> sorry, I was the one proposing checking other projects. I didnt have time this week
20:38:45 <Alex_Staf> I think that when an operator create load balancer or loadbalancing related stuff we have to have loadbalancer in line
20:38:58 <jniesz> I kind of like being more explicit
20:39:02 <johnsom> 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 <Alex_Staf> and if we look on other loadbalancer stuff it is loadbalancer pool, listener , health monitor , etc
20:39:19 <cgoncalves_> 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 <xgerman_> +!
20:39:52 <cgoncalves_> xgerman_: is that a yes or a no? :)
20:39:58 <xgerman_> yes
20:40:04 <johnsom> 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 <Alex_Staf> lol
20:40:40 <cgoncalves_> xgerman_: skip the review of skoda octavia please :P
20:40:43 <johnsom> 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 <johnsom> lol
20:41:36 <johnsom> Ok, please vote. I am going to move on to the next topic
20:41:37 <xgerman_> yeah, I think we should pick that up as the whole provider driver refactor/rework
20:41:54 <jniesz> are we ever going to have other drive specific cli options?
20:41:54 <johnsom> #topic Octavia testing planning
20:42:06 <johnsom> #link https://etherpad.openstack.org/p/octavia-testing-planning
20:42:10 <jniesz> if that is the case I think it is important to have driver in name
20:42:12 <Alex_Staf> yoohooo
20:42:54 <johnsom> 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 <johnsom> Ok, all things test planning
20:43:52 <johnsom> I was not able to find the link to the old test plan google doc.
20:44:07 <johnsom> Actually, fnaval might still have it if he is arround
20:44:49 <fnaval> hi - I don't think I ever had a testplan for Octavia
20:44:56 <johnsom> 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 <fnaval> but I think I had one for neutron lbaas
20:45:08 <Alex_Staf> ok so I have written a plan but it is scenario only test , with traffic and HA .
20:45:10 <xgerman_> yep, same thing
20:45:16 <Alex_Staf> nope , it is general questions
20:45:18 <johnsom> fnaval Yeah, we had a google doc spreadsheet with a test matrix/plan
20:45:42 <johnsom> fnaval If you happen to still have a link around...
20:45:47 <fnaval> checking
20:46:27 <xgerman_> Thx
20:46:30 <johnsom> 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 <johnsom> functional is where Octavia is "weird".
20:48:02 <johnsom> We have functional tests that run against live DB and API without a full devstack running.
20:48:18 <johnsom> This is good as they are fast.
20:48:32 <fnaval> https://docs.google.com/spreadsheets/d/1MxAAQ33rS4iH4ekwsW8DnZyKxi7oE4TZeHvJcM6STyY/edit?usp=sharing
20:48:34 <fnaval> https://docs.google.com/spreadsheets/d/1EBIwBEL5Tyzc2nU_05uqCRP5mjEvZAlhdmzhKjQl8sg/edit?usp=sharing
20:48:38 <johnsom> Down side is they are in-tree, so are branch specific
20:48:48 <xgerman_> thanks fnaval
20:49:13 <fnaval> yep
20:49:16 <johnsom> Ah, the second one is not right
20:49:47 <fnaval> that probably is the internal implementation
20:50:23 <johnsom> #link https://docs.google.com/spreadsheets/d/1MxAAQ33rS4iH4ekwsW8DnZyKxi7oE4TZeHvJcM6STyY/edit?usp=sharing
20:50:30 <johnsom> That is what we were looking for
20:50:34 <fnaval> kk
20:52:02 <johnsom> The question I have about our current functional is it overlaps with what is typically done with tempest API tests
20:52:19 <johnsom> Do we need/want both?
20:52:47 <Alex_Staf> we have functional ? I mean automated
20:53:09 <johnsom> Alex_Staf Yes
20:53:23 <johnsom> #link https://github.com/openstack/octavia/tree/master/octavia/tests/functional
20:54:06 <johnsom> #link http://logs.openstack.org/38/521138/21/check/openstack-tox-functional/5857e19/testr_results.html.gz
20:54:18 <Alex_Staf> I think if it overlaps API only is ok
20:54:34 <rm_mobile|> I think they are useful to have in tree and would be sad if they're gone
20:55:15 <johnsom> 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 <johnsom> Alex_Staf not sure I follow your comment.
20:57:19 <Alex_Staf> which one ?
20:57:30 <johnsom> The overlaps one
20:58:12 <Alex_Staf> ignore missread your question regarding API and functional overlapping
20:58:19 <johnsom> We are about out of time, bummer.
20:58:41 <johnsom> Maybe we can fill this in a bit more and pick it up as the first topic next week.
20:58:50 <Alex_Staf> ok so I wil ltry to use what we have in API functions to write more complex tests.
20:59:28 <Alex_Staf> We have basic functions for for LB objects creation , I will try to work with that
20:59:31 <johnsom> 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 <johnsom> Let me try to write up more in the etherpad for next week.
21:00:16 <johnsom> #endmeeting