20:00:01 #startmeeting Octavia 20:00:02 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:06 The meeting name has been set to 'octavia' 20:00:11 o/ 20:00:21 Hi there 20:00:27 hey 20:00:31 hi 20:00:42 <[1]evgenyf> o/ 20:00:47 I will give it a minute for the not-so-punctual.... 20:01:00 hi 20:01:01 sure 20:01:29 #topic Announcements 20:01:32 hello 20:01:42 Ocata-2 is week of December 12th 20:01:55 So, next week folks. 20:02:17 We have setup a merge priority review list here: 20:02:24 #link https://etherpad.openstack.org/p/octavia-ocata-merge-review-priority 20:02:46 Please help us review patches and help us make sure it is quality 20:02:53 o/ 20:03:33 once i get this image building issue dealt with, i'll be able to test/merge the keystone thing 20:03:36 Other news, diskimage-builder made a change to one of the elements, which broke us, last friday. 20:03:46 Yeah, ^^^ that 20:03:52 :/ 20:04:12 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 Thanks rm_work for working with them on that 20:04:43 Two other quick items 20:04:58 I have a patch up to add our channel to the infra status bot 20:05:16 I want this so we get notified when things are broken and rechecks are useless 20:05:58 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 Any other announcements? 20:06:50 Ah, one other thing I almost forgot 20:07:03 I have moved all of the neutron-lbaas bugs out of the neutron launchpad. 20:07:08 is the infra bot patch linked somewhere? 20:07:37 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 #link https://review.openstack.org/407609 20:08:00 <[1]evgenyf> same second ) 20:08:26 #link https://bugs.launchpad.net/octavia/+bugs?field.tag=lbaas 20:08:48 <[1]evgenyf> johnsom: thanks 20:08:55 The pretty logs patch is here: 20:09:02 #link https://review.openstack.org/408246 20:09:08 Just for completeness grin 20:10:24 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 #topic Brief progress reports / bugs needing review 20:11:29 yeah the mailing list is more timezone-friendly so I've picked that from there :) 20:11:57 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 cool 20:12:26 #link https://wiki.openstack.org/wiki/Octavia/Meeting_Minutes 20:12:39 kobis You can always read the exciting minutes/log too... grin 20:13:03 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 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 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 Ok, sounds good. 20:15:17 Any other updates folks want to give? 20:15:23 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 Can we do a mailing list chain? I think it would catch more folks 20:16:22 we can run the etherpad via the mailing list :D 20:16:24 Or, I guess an e-mail that points to the etherpad 20:16:32 Yep 20:16:36 Hi 20:16:54 kobis Are you volunteering to lead that? 20:17:06 doable ;) 20:17:35 #action kobis to e-mail the dev list about changing the meeting time. 20:18:10 #topic Requesting help with neutron-lbaas-dashboard\ 20:18:15 #undo 20:18:15 Removing item from minutes: 20:18:22 #topic Requesting help with neutron-lbaas-dashboard 20:18:33 what is wrong with the lbaas dashboard? 20:18:45 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 but why? it was working 20:19:29 It was released for Mitaka, but nothing in OpenStack is ever completed it seems. 20:19:30 and stopped working without anyone help? 20:19:46 the only broken thing which i'm aware of, is lack of newton release tag 20:19:50 Unfortunately I think we have also lost all of the folks that were working on it. 20:19:56 are you refering to this bug https://bugs.launchpad.net/neutron-lbaas-dashboard/+bug/1621403 20:19:56 Launchpad bug 1621403 in Neutron LBaaS Dashboard "Not showing neutron-lbaas-dashboard even after enabled" [Critical,New] 20:20:15 yet I've checked that a about a week ago 20:20:20 Yes, I think there might be others in there too 20:20:53 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 idk who should have created that tag 20:21:45 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 ankur-gupta-f That is interesting, there was someone on the channel today asking about it saying it wasn't working. 20:22:39 johnsom: ic. so M=N from dashboard aspect? 20:23:18 What I am asking for is if there are folks that can work on it, at least from a maintenance perspective? 20:23:31 kobis Right. 20:23:56 It could use some TLC 20:24:03 I have some experience and can take a look 20:24:09 rebuilding devstack right now with it enabled 20:24:23 ankur-gupta-f Great! Appreciate it. 20:25:19 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 #topic Open Discussion 20:26:22 Ok, shall we start with evgenyf? 20:26:27 <[1]evgenyf> Yes 20:26:28 flavors 20:26:52 so I'm reviewing that right now 20:27:07 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 Nice 20:27:57 <[1]evgenyf> I will make efforts to put it on review next week 20:28:39 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 johnsom: I do feel that from LB vendor perspective, flavors are more important than in general neutron context 20:30:13 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 agree 20:30:59 <[1]evgenyf> johnsom: ok 20:31:06 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 Cool, looking forward to the new proposal. 20:32:41 Once we get through this merge stuff, I do hope we continue to add common features to the API. 20:33:14 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 Timeouts, backend re-encryption are two on the top of my mind. 20:33:53 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 rm_work well maybe its worthwhile to share that before evgenyf updates the rst 20:34:23 nothing really complex beyond the standard discussion on flavors 20:34:48 basically, bronze flavor -> haproxy in VM (octavia), gold -> shared A10, platinum -> dedicated f5 20:34:48 #link https://review.openstack.org/#/c/392485/ 20:34:50 etc 20:34:52 but for me is interesting what is the idea about connectivity from Octavia to like F5 20:35:24 well, since octavia is just pulling in the drivers from n-lbaas as shims or whatever 20:35:49 rm_work: but it may be also done replacing octavia amphora driver 20:36:16 based on that we need to really take a look into supporting multi drivers flavors 20:36:50 like flavor should be able to replace amphora driver and like add nlbaas compatible driver 20:36:51 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 I know but we need to even enable transition 20:37:34 Right. This is the next topic on my list 20:37:35 i agree that multi-provider support is essential for octavia-as-lbaas effort 20:37:50 kobis +1 yes 20:38:10 blogan started that work, but has made slow progress. 20:38:28 johnsom: multi-provider work? 20:38:44 so I'm gonna help blogan with that work 20:38:54 and maybe in mean time to work on filtering 20:39:01 [1]evgenyf kobis My next topic is about third party ci and ways blogan can test the driver work 20:39:11 witch will be aligned with api-wg 20:39:38 johnsom thought that a10 was the test case for this 20:40:15 anyway both radware and vmware drivers need minor (radware) or major (vmware) rework to work in octavia context 20:40:36 Yes, they were, but I'm not sure that is working out. blogan are you still looking for other guinea pigs? 20:40:54 kobis: how much do thsoe drivers change thigns via the core plugin that cannot be done through the neutron API? 20:41:19 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 i'm guessing that for radware it's fairly easy to work via neutron api (but evgenyf should answer that really) 20:42:00 ^ :) 20:42:12 [1]evgenyf: great! 20:42:35 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 vmware: it's a pain as vmware is the neutron plugin as well as the lbaas driver 20:42:52 kobis: but you're still communicating via rpc no? 20:42:58 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 or maybe that was the idea i had to solve it 20:43:22 blogan: we do not communicate via rpc: we make direct calls to the core plugin 20:43:33 kobis: ok i had my memory mixed up then 20:43:59 kobis: yeah so vmware's will definitely be one that will be almost impossible to do without direct intervention 20:44:02 from teh driver writers 20:44:16 you I still assume 20:44:21 so i'm guessing that i'll have to write a neutron extension which will be called from octavia context 20:44:49 kobis: you could do taht, or just communicate via rpc callbacks and such 20:45:22 blogan: doable too 20:45:48 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 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 kobis: is it an ml2 driver? or a core plugin? 20:46:54 its a plugin 20:46:56 core plugin... 20:47:28 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 i'm putting this in vmware-nsx repo. and our plugin loads it… technically its pretty simple 20:49:43 thing is that even if i code this tomorrow, i can't test it in any way 20:49:54 right? 20:50:41 using that old nlbaas drivers api - no you're not able 20:51:33 based no that johnsom was asking about providing gates for drivers 20:52:15 I wanted to bring up the topic so we can have all of the resources we need and align the work. 20:52:38 we should also identify the dependencies each phase needs 20:52:41 diltram nlbaas runs within neutron therefore n-client isn't present 20:53:31 kobis: so you're calling directly neutron cli to execute some stuff? 20:53:41 cli? 20:53:42 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 kobis: client 20:54:18 johnsom: to test it out, wouldn't a passthrough nlbaas plugin be needed OR the octavia API accepting nlbaas calls? 20:54:45 Right, octavia API will be first. 20:54:48 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 when this drivers run in octavia context, calls to neutron should be done via the rest client 20:56:12 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 [1]evgenyf: no thats not in the scope of what i was donig, that woudl be a separate effort 20:57:14 but it shouldn't be terribly hard 20:57:16 right now you just pick ONE? 20:57:25 yeah just ONE, whatever is in the config 20:57:31 well, without flavors that makes sense because there'd be no way in the API to select 20:57:31 blogan: so we can work around missing octavia client by using nlbaas 20:57:48 nlbaas allows the provider attribute on the load balancer 20:57:51 so we'd have to accept that as wel 20:57:52 l 20:57:58 rm_work Well neutron-lbaas has a "providers" option 20:57:58 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 rm_work yes 20:58:26 kobis: well there needs to be a passthrough type of plugin in nlbaas for that to work 20:58:47 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 did we talk about the structure in OSC at all yet? 20:59:04 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 i may be off topic, i'll wait 20:59:12 We are about out of time. 20:59:15 though we're just about out of time 20:59:16 yeah 20:59:25 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 i would like to discuss OSC stuff at some point but it doesn't have to be today 20:59:32 maybe next meeting 20:59:37 OSC is deferred to Pike 20:59:43 lol 20:59:45 k 20:59:45 johnsom: yes but the nlbaas client won't work otu of the box without the nlbaas pasthrough 20:59:48 :) 21:00:06 Let's move to the lbaas channel 21:00:11 #endmeeting