20:00:01 <johnsom> #startmeeting Octavia
20:00:02 <openstack> Meeting started Wed Dec  7 20:00:01 2016 UTC and is due to finish in 60 minutes.  The chair is johnsom. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:06 <openstack> The meeting name has been set to 'octavia'
20:00:11 <diltram> o/
20:00:21 <johnsom> Hi there
20:00:27 <diltram> hey
20:00:31 <sindhu> hi
20:00:42 <[1]evgenyf> o/
20:00:47 <johnsom> I will give it a minute for the not-so-punctual....
20:01:00 <kobis> hi
20:01:01 <diltram> sure
20:01:29 <johnsom> #topic Announcements
20:01:32 <ankur-gupta-f> hello
20:01:42 <johnsom> Ocata-2 is week of December 12th
20:01:55 <johnsom> So, next week folks.
20:02:17 <johnsom> We have setup a merge priority review list here:
20:02:24 <johnsom> #link https://etherpad.openstack.org/p/octavia-ocata-merge-review-priority
20:02:46 <johnsom> Please help us review patches and help us make sure it is quality
20:02:53 <rm_work> o/
20:03:33 <rm_work> once i get this image building issue dealt with, i'll be able to test/merge the keystone thing
20:03:36 <johnsom> Other news, diskimage-builder made a change to one of the elements, which broke us, last friday.
20:03:46 <johnsom> Yeah, ^^^ that
20:03:52 <diltram> :/
20:04:12 <johnsom> I put some quick patches out, but the DIB folks wanted to address it a different way, so it's dragging on a bit.
20:04:20 <johnsom> Thanks rm_work for working with them on that
20:04:43 <johnsom> Two other quick items
20:04:58 <johnsom> I have a patch up to add our channel to the infra status bot
20:05:16 <johnsom> I want this so we get notified when things are broken and rechecks are useless
20:05:58 <johnsom> I also have another patch up that will make our octavia logs look a little better and have the "ERROR" etc. filters.
20:06:14 <johnsom> Any other announcements?
20:06:50 <johnsom> Ah, one other thing I almost forgot
20:07:03 <johnsom> I have moved all of the neutron-lbaas bugs out of the neutron launchpad.
20:07:08 <rm_work> is the infra bot patch linked somewhere?
20:07:37 <johnsom> They are now in the octavia project launchpad and tagged with "lbaas"
20:07:45 <[1]evgenyf> where are neutron-lbaas bugs now?
20:07:45 <johnsom> #link https://review.openstack.org/407609
20:08:00 <[1]evgenyf> same second )
20:08:26 <johnsom> #link https://bugs.launchpad.net/octavia/+bugs?field.tag=lbaas
20:08:48 <[1]evgenyf> johnsom: thanks
20:08:55 <johnsom> The pretty logs patch is here:
20:09:02 <johnsom> #link https://review.openstack.org/408246
20:09:08 <johnsom> Just for completeness grin
20:10:24 <johnsom> BTW, a few folks have joined that weren't on the meeting last week.  The governance change to make Octavia a top level project passed the TC.  This includes the governance part of the merge, thus moving the bugs
20:11:08 <johnsom> #topic Brief progress reports / bugs needing review
20:11:29 <kobis> yeah the mailing list is more timezone-friendly so I've picked that from there :)
20:11:57 <johnsom> So, yeah, I have been busy with PTL stuff around the governance change.  I have also been working on the quota patch.  I plan to have that up for review today.
20:12:11 <rm_work> cool
20:12:26 <johnsom> #link https://wiki.openstack.org/wiki/Octavia/Meeting_Minutes
20:12:39 <johnsom> kobis You can always read the exciting minutes/log too...  grin
20:13:03 <rm_work> I wonder if we could pick a time that's better for people now that most of the contributors are PST and international, we lost most of our CST folks :/
20:13:46 <[1]evgenyf> I read it sometimes, exciting
20:13:56 <johnsom> I am open to that.  If someone wants to find a timeslot on the OpenStack meeting channels and propose it on the mailing list, please do.
20:14:21 <[1]evgenyf> link# https://review.openstack.org/#/c/392485
20:14:38 <johnsom> Otherwise I know there has been a lot of work going on around the merge.  So good stuff there.
20:14:39 <[1]evgenyf> I would like to discuss the above patch on open discussion
20:15:00 <[1]evgenyf> It' theh flavors RST
20:15:07 <johnsom> Ok, sounds good.
20:15:17 <johnsom> Any other updates folks want to give?
20:15:23 <kobis> maybe we can run an etherpad where everyone can place their TZ so figuring out a good meeting time will be easier?
20:16:00 <johnsom> Can we do a mailing list chain?  I think it would catch more folks
20:16:22 <kobis> we can run the etherpad via the mailing list :D
20:16:24 <johnsom> Or, I guess an e-mail that points to the etherpad
20:16:32 <johnsom> Yep
20:16:36 <perelman> Hi
20:16:54 <johnsom> kobis Are you volunteering to lead that?
20:17:06 <kobis> doable ;)
20:17:35 <johnsom> #action kobis to e-mail the dev list about changing the meeting time.
20:18:10 <johnsom> #topic Requesting help with neutron-lbaas-dashboard\
20:18:15 <johnsom> #undo
20:18:15 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x7f63d9a776d0>
20:18:22 <johnsom> #topic Requesting help with neutron-lbaas-dashboard
20:18:33 <ankur-gupta-f> what is wrong with the lbaas dashboard?
20:18:45 <johnsom> It has come to my attention that the dashboard is in a broken state
20:18:48 <[1]evgenyf> it isn't completed right?
20:19:18 <diltram> but why? it was working
20:19:29 <johnsom> It was released for Mitaka, but nothing in OpenStack is ever completed it seems.
20:19:30 <diltram> and stopped working without anyone help?
20:19:46 <kobis> the only broken thing which i'm aware of, is lack of newton release tag
20:19:50 <johnsom> Unfortunately I think we have also lost all of the folks that were working on it.
20:19:56 <ankur-gupta-f> are you refering to this bug https://bugs.launchpad.net/neutron-lbaas-dashboard/+bug/1621403
20:19:56 <openstack> Launchpad bug 1621403 in Neutron LBaaS Dashboard "Not showing neutron-lbaas-dashboard even after enabled" [Critical,New]
20:20:15 <kobis> yet I've checked that a about a week ago
20:20:20 <johnsom> Yes, I think there might be others in there too
20:20:53 <ankur-gupta-f> I had no problem with it off of master branch last week. Except for the fact that I think it belongs in the Admin portion of Horizon.
20:21:03 <kobis> idk who should have created that tag
20:21:45 <johnsom> kobis Me.  I didn't do a release as I didn't see any real changes in newton and Doug wasn't sure if anyone was working on it.
20:22:26 <johnsom> ankur-gupta-f That is interesting, there was someone on the channel today asking about it saying it wasn't working.
20:22:39 <kobis> johnsom: ic. so M=N from dashboard aspect?
20:23:18 <johnsom> What I am asking for is if there are folks that can work on it, at least from a maintenance perspective?
20:23:31 <johnsom> kobis Right.
20:23:56 <johnsom> It could use some TLC
20:24:03 <ankur-gupta-f> I have some experience and can take a look
20:24:09 <ankur-gupta-f> rebuilding devstack right now with it enabled
20:24:23 <johnsom> ankur-gupta-f Great!  Appreciate it.
20:25:19 <johnsom> I think there are also features that were never added, like L7, etc.  So, if any of you have some horizon folks with cycles, neutron-lbaas-dashboard can use some help.
20:25:59 <johnsom> #topic Open Discussion
20:26:22 <johnsom> Ok, shall we start with evgenyf?
20:26:27 <[1]evgenyf> Yes
20:26:28 <johnsom> flavors
20:26:52 <diltram> so I'm reviewing that right now
20:27:07 <diltram> but the biggest issue for me is  multi drivers support
20:27:07 <[1]evgenyf> After your reviews on flavors RST, kobis and myself had a little brainstorm
20:27:33 <[1]evgenyf> and came to some simpler and better design in our opinion
20:27:38 <johnsom> Nice
20:27:57 <[1]evgenyf> I will make efforts to put it on review next week
20:28:39 <johnsom> I am not stuck on flavors.  It really never got implemented in neutron from what I can see
20:28:47 <[1]evgenyf> And we also discussed an option of merging multi-provider task and flavors task
20:29:22 <[1]evgenyf> It may make RST clearer
20:29:37 <kobis> johnsom: I do feel that from LB vendor perspective, flavors are more important than in general neutron context
20:30:13 <johnsom> Hmm, ok.  We will need to support backward compatibility with the "providers" currently in neutron-lbaas, at least for a deprecation cycle.
20:30:55 <kobis> agree
20:30:59 <[1]evgenyf> johnsom: ok
20:31:06 <johnsom> kobis Yeah, I get the use case.  However, I also don't feel right about it becoming an excuse to not just add to the lbaas API either.
20:31:18 <[1]evgenyf> johnsom: good poin
20:31:23 <[1]evgenyf> point
20:32:04 <johnsom> Cool, looking forward to the new proposal.
20:32:41 <johnsom> Once we get through this merge stuff, I do hope we continue to add common features to the API.
20:33:14 <rm_work> sorry late, but flavors will be important with what i'm working on as well
20:33:40 <[1]evgenyf> rm_work: what is it?
20:33:50 <johnsom> Timeouts, backend re-encryption are two on the top of my mind.
20:33:53 <rm_work> it'll be very important to be able to have the ability to deploy different backends based on flavor (haproxy-vm per Octavia currently, but also other stuff like F5s or whatever as a different flavor)
20:34:02 <kobis> rm_work well maybe its worthwhile to share that before evgenyf updates the rst
20:34:23 <rm_work> nothing really complex beyond the standard discussion on flavors
20:34:48 <rm_work> basically, bronze flavor -> haproxy in VM (octavia), gold -> shared A10, platinum -> dedicated f5
20:34:48 <johnsom> #link https://review.openstack.org/#/c/392485/
20:34:50 <rm_work> etc
20:34:52 <diltram> but for me is interesting what is the idea about connectivity from Octavia to like F5
20:35:24 <rm_work> well, since octavia is just pulling in the drivers from n-lbaas as shims or whatever
20:35:49 <diltram> rm_work: but it may be also done replacing octavia amphora driver
20:36:16 <diltram> based on that we need to really take a look into supporting multi drivers flavors
20:36:50 <diltram> like flavor should be able to replace amphora driver and like add nlbaas compatible driver
20:36:51 <johnsom> The current driver model isn't going away.  Certainly the vendor could opt for a amphora model, but that is optional, etc.
20:37:16 <diltram> I know but we need to even enable transition
20:37:34 <johnsom> Right.  This is the next topic on my list
20:37:35 <kobis> i agree that multi-provider support is essential for octavia-as-lbaas effort
20:37:50 <johnsom> kobis +1 yes
20:38:10 <johnsom> blogan started that work, but has made slow progress.
20:38:28 <blogan> johnsom: multi-provider work?
20:38:44 <diltram> so I'm gonna help blogan with that work
20:38:54 <diltram> and maybe in mean time to work on filtering
20:39:01 <johnsom> [1]evgenyf kobis My next topic is about third party ci and ways blogan can test the driver work
20:39:11 <diltram> witch will be aligned with api-wg
20:39:38 <kobis> johnsom thought that a10 was the test case for this
20:40:15 <kobis> anyway both radware and vmware drivers need minor (radware) or major (vmware) rework to work in octavia context
20:40:36 <johnsom> Yes, they were, but I'm not sure that is working out.  blogan are you still looking for other guinea pigs?
20:40:54 <blogan> kobis: how much do thsoe drivers change thigns via the core plugin that cannot be done through the neutron API?
20:41:19 <blogan> johnsom: i'm currently trying to do the namespace driver one as a guinea pig
20:41:49 <[1]evgenyf> blogan: for radware probably nothing
20:41:52 <kobis> i'm guessing that for radware it's fairly easy to work via neutron api (but evgenyf should answer that really)
20:42:00 <kobis> ^ :)
20:42:12 <blogan> [1]evgenyf: great!
20:42:35 <blogan> thats the one caveat that will be an issue, if its doing stuff that can't be done via the neutron API then that part of the driver cannot be done via the shim
20:42:37 <kobis> vmware: it's a pain as vmware is the neutron plugin as well as the lbaas driver
20:42:52 <blogan> kobis: but you're still communicating via rpc no?
20:42:58 <kobis> both are actually nsx and resources are shared
20:43:05 <[1]evgenyf> everything it does with neutron core could be done with octavia's neutron plugin
20:43:09 <blogan> or maybe that was the idea i had to solve it
20:43:22 <kobis> blogan: we do not communicate via rpc: we make direct calls to the core plugin
20:43:33 <blogan> kobis: ok i had my memory mixed up then
20:43:59 <blogan> kobis: yeah so vmware's will definitely be one that will be almost impossible to do without direct intervention
20:44:02 <blogan> from teh driver writers
20:44:16 <blogan> you I still assume
20:44:21 <kobis> so i'm guessing that i'll have to write a neutron extension which will be called from octavia context
20:44:49 <blogan> kobis: you could do taht, or just communicate via rpc callbacks and such
20:45:22 <kobis> blogan: doable too
20:45:48 <blogan> i feel like that would be better bc then you won't need to go through the process having it be an acceptable neturon API extension
20:46:40 <kobis> yup but as of now i'm not sure that the vmware neutron plugin is even using rpc for any other purpose
20:46:42 <blogan> kobis: is it an ml2 driver? or a core plugin?
20:46:54 <blogan> its a plugin
20:46:56 <kobis> core plugin...
20:47:28 <blogan> well then you wouldn't be putting it in neutron's tree anyway, and its probably not in teh stadium, so yeah as long as the users know you need that extension
20:48:25 <kobis> i'm putting this in vmware-nsx repo. and our plugin loads it… technically its pretty simple
20:49:43 <kobis> thing is that even if i code this tomorrow, i can't test it in any way
20:49:54 <kobis> right?
20:50:41 <diltram> using that old nlbaas drivers api - no you're not able
20:51:33 <diltram> based no that johnsom was asking about providing gates for drivers
20:52:15 <johnsom> I wanted to bring up the topic so we can have all of the resources we need and align the work.
20:52:38 <blogan> we should also identify the dependencies each phase needs
20:52:41 <kobis> diltram nlbaas runs within neutron therefore n-client isn't present
20:53:31 <diltram> kobis: so you're calling directly neutron cli to execute some stuff?
20:53:41 <kobis> cli?
20:53:42 <johnsom> So it sounds to me like we need the basic shim done, then we can start on the non-haproxy drivers.  Is there more detail blogan?
20:54:07 <diltram> kobis: client
20:54:18 <blogan> johnsom: to test it out, wouldn't a passthrough nlbaas plugin be needed OR the octavia API accepting nlbaas calls?
20:54:45 <johnsom> Right, octavia API will be first.
20:54:48 <kobis> client=rest client. as of now nlbaas is running in neutron process context so it can make direct calls to the core plugin
20:55:29 <kobis> when this drivers run in octavia context, calls to neutron should be done via the rest client
20:56:12 <diltram> kobis: ok, I understand
20:56:43 <[1]evgenyf> blogan: In your work with A10 driver as an other provider in Octavia, is there multi providers loading work?
20:57:03 <blogan> [1]evgenyf: no thats not in the scope of what i was donig, that woudl be a separate effort
20:57:14 <blogan> but it shouldn't be terribly hard
20:57:16 <rm_work> right now you just pick ONE?
20:57:25 <blogan> yeah just ONE, whatever is in the config
20:57:31 <rm_work> well, without flavors that makes sense because there'd be no way in the API to select
20:57:31 <kobis> blogan: so we can work around missing octavia client by using nlbaas
20:57:48 <blogan> nlbaas allows the provider attribute on the load balancer
20:57:51 <blogan> so we'd have to accept that as wel
20:57:52 <blogan> l
20:57:58 <johnsom> rm_work Well neutron-lbaas has a "providers" option
20:57:58 <rm_work> so technically the n-lbaas client *will work* won't it? once we finish the merge
20:58:08 <[1]evgenyf> That backward compatability to nlbaas providers format is limiting
20:58:21 <johnsom> rm_work yes
20:58:26 <blogan> kobis: well there needs to be a passthrough type of plugin in nlbaas for that to work
20:58:47 <rm_work> although i'm already getting deprecation warnings on the n-lbaas-cli so we really need to move it to OSC soon >_>
20:59:03 <rm_work> did we talk about the structure in OSC at all yet?
20:59:04 <johnsom> blogan yes.  The API direct will be working sooner than the pass through.  The API patches are starting to go up for review/WIP
20:59:12 <rm_work> i may be off topic, i'll wait
20:59:12 <johnsom> We are about out of time.
20:59:15 <rm_work> though we're just about out of time
20:59:16 <rm_work> yeah
20:59:25 <blogan> well either way, the client is getting the neutron endpoitn from the keystone catalog and just appending /lbaas to the neutron endpoint, so the neutron-server needs to handle calls to that and redirect to the octavia endpoint
20:59:29 <rm_work> i would like to discuss OSC stuff at some point but it doesn't have to be today
20:59:32 <rm_work> maybe next meeting
20:59:37 <johnsom> OSC is deferred to Pike
20:59:43 <rm_work> lol
20:59:45 <rm_work> k
20:59:45 <blogan> johnsom: yes but the nlbaas client won't work otu of the box without the nlbaas pasthrough
20:59:48 <kobis> :)
21:00:06 <johnsom> Let's move to the lbaas channel
21:00:11 <johnsom> #endmeeting