20:00:06 #startmeeting Octavia 20:00:07 Meeting started Wed Mar 15 20:00:06 2017 UTC and is due to finish in 60 minutes. The chair is johnsom. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:08 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:10 The meeting name has been set to 'octavia' 20:00:29 o/ 20:00:33 Congrats to those that followed DST changed the time... 20:00:34 o/ 20:00:56 I learned my lesson over the years to put in my appointment in UTC 20:00:56 #topic Announcements 20:01:03 Yep, me too 20:01:09 plz invite me to your meeting :P 20:01:27 rm_work will do 20:01:45 We have four presentations for the Boston Summit. Should be busy. 20:01:54 Hands on Lab: Octavia 20:02:00 #link https://www.openstack.org/summit/boston-2017/summit-schedule/events/17583/hands-on-lab-octavia 20:02:05 Octavia: Load Balancing for OpenStack 20:02:13 #link https://www.openstack.org/summit/boston-2017/summit-schedule/events/17859/octavia-load-balancing-for-openstack 20:02:20 Project Update - Octavia 20:02:26 #link https://www.openstack.org/summit/boston-2017/summit-schedule/events/18611/project-update-octavia 20:02:34 Introduction to OpenStack Load Balancing 20:02:40 #link https://www.openstack.org/summit/boston-2017/summit-schedule/events/17862/introduction-to-openstack-load-balancing 20:02:48 So that is awesome 20:03:35 I will get started on the slides maybe next week. I plan to do the google doc thing again so folks can contribute. 20:04:04 Another announcement is our shiny new repos merged today 20:04:06 cool - rm_work wonde rif youstill have the scripts we used for the last lab 20:04:06 o/ 20:04:18 python-octaviaclient - For our OpenStack Client plugin 20:04:43 octavia-dashboard - A copy of the neutron-lbaas-dashboard that will target the new Octavia endpoint 20:04:44 xgerman: hmmm, i had some thoughts about that 20:04:53 but we'll talk :P 20:05:01 sounds good 20:05:23 octavia-tempest-plugin - Tempest plugin repo to get ahead of the proposed queens goal and we can clean up our Tempest situation 20:05:54 Any other announcements or questions? 20:06:12 topic of the day is octavia/dib co-gate i think 20:06:24 but we'll get to that in ... open discussion? 20:06:30 openstack-ansible for Ocavia has merged 20:06:33 The octavia core team has access, but I setup separate ACLs so we can have others for specific repos. 20:06:45 xgerman Nice!!!! +100 20:06:58 xgerman: awesome :) 20:07:08 I'm gonna test it in near future 20:07:14 cool 20:07:28 Yeah, I am anxious to try it out too. Won't have time for a bit, but excited. 20:08:06 Now if we can just convince diltram to send us all NUCs.... 20:08:14 :P 20:08:16 no way 20:08:19 they mine 20:08:30 * johnsom thought he would try.... 20:08:41 #topic Brief progress reports / bugs needing review 20:08:47 maybe we should port it to rasperry pi 20:09:05 I am telling you embedded OpenStack will be huge, or bigly 20:09:19 I am trying to get testing done on the LB API patch. Had a hiccup yesterday, but will be back on that today. 20:09:32 easy one: https://review.openstack.org/#/c/446144/ 20:09:53 Yep, done 20:09:59 https://review.openstack.org/#/c/303304/ 20:10:06 I know that passes as it was in the other patch earlier 20:10:13 rm_work: I'm gonna wait for test results 20:10:18 right 20:10:21 do that :P 20:10:23 but it'll pass 20:10:48 ah yeah it did already 20:10:48 xgerman it looks like it has a pep8 issue? 20:11:02 but it was fixed 20:11:08 huh 20:11:14 ok, we will sort that out 20:11:26 it's again the E402 20:11:43 Ah, that is a quick fix 20:12:11 diltram: gate-octavia-tox-functional-py35-ubuntu-xenial: SUCCESS 20:12:43 Grin 20:12:53 Ok, if nothing else here, moving on 20:13:00 #topic Team mascot 20:13:06 #link https://etherpad.openstack.org/p/octavia-mascot 20:13:13 Looks like we have a tie 20:13:26 peacock or tree with roots 20:13:50 Though I am still partial to canary.... hahaha 20:14:10 #vote, #vote 20:14:26 Has everyone voted? 20:14:46 rm_work: I'm still not seeing results :P 20:14:52 johnsom: I voted 20:14:58 me, too 20:15:12 diltram: look in zuul :P 20:15:23 should we do a second round with limited options?? 20:15:47 #startvote Team mascot? Peacock, Tree 20:15:48 Begin voting on: Team mascot? Valid vote options are Peacock, Tree. 20:15:49 Vote using '#vote OPTION'. Only your last vote counts. 20:15:55 Just to honor dougwig 20:16:19 #vote Tree 20:16:29 you could have gotten canary in there 20:16:35 ah well 20:16:41 #vote Peacock 20:16:44 #vote Canary 20:16:45 rm_work: Canary is not a valid option. Valid options are Peacock, Tree. 20:16:52 hahaha 20:16:56 #vote Tree 20:17:00 rm_work: :P 20:17:02 #vote peacock 20:17:03 always a joker in the crowd 20:17:11 in what way is a peacock load-balancing exactly? 20:17:15 #vote peacock 20:17:16 was trying to understand that 20:17:30 Something about fanning out.. 20:17:41 ah 20:17:52 too bad ‘hydra’ isn’t an option 20:17:58 i mean roots are literally load-bearing 20:17:59 but no big deal :P 20:18:00 wait 20:18:01 it is now ;-) 20:18:01 is it not? 20:18:01 rm_work: when I will see jenkins +1 20:18:02 HEIL HYDRA 20:18:14 no mythical creatures? 20:18:19 fff 20:18:35 Right 20:18:54 #vote Ignore the stupid "no mythical creatures rule"? Yes, Duh 20:18:55 rm_work: Ignore the stupid "no mythical creatures rule"? Yes, Duh is not a valid option. Valid options are Peacock, Tree. 20:18:57 I like the root thing 20:19:02 #vote Tree 20:19:07 ah that was supposed to be startvote 20:19:10 ah well 20:19:18 Going once..... 20:19:24 Going twice.... 20:19:27 #vote Tree 20:19:27 #endvote 20:19:28 Voted on "Team mascot?" Results are 20:19:29 Peacock (2): m-greene-, xgerman 20:19:30 Tree (3): diltram, rm_work, johnsom 20:19:56 I will follow up with the foundation and they will give us some renderings 20:19:58 both of those are very calm 20:20:07 not like Fire or Supernova 20:20:30 rm_work: your patch is failing on lbaasv2-dsvm 20:20:31 Tree implies solid, reliable 20:20:33 Is perelman here today? 20:20:41 diltram: false positive, OVH, 99% sure 20:20:43 let me check 20:20:51 I didn't change anything that would run there :P 20:21:09 oh, neutron-lbaasv2? 20:21:12 everything fails those 20:21:14 yep 20:21:16 Ok, skipping Act/Act discussion. Same status as last week 20:21:29 #topic flavors 20:21:31 until DIB releases 20:21:37 I think 20:21:38 Any updates on the flavors spec? 20:21:53 well, we might recap the Walmart meet 20:21:57 oh the API too, weird 20:22:10 #link https://review.openstack.org/392485 20:22:19 diltram: neutron-lbaas bug 20:22:24 I see 20:22:27 xgerman Yeah, that is a good idea. Coming up. 20:22:28 diltram: http://logs.openstack.org/44/446144/1/check/gate-neutron-lbaasv2-dsvm-api-ubuntu-xenial/8cdc9d8/logs/devstacklog.txt.gz#_2017-03-15_19_54_15_754 20:22:51 Ok, no update on flavors either. 20:23:00 #topic When should we lock neutron-lbaas for new features? 20:23:03 I haven’t reviwed again since PTG 20:23:08 #vote right now 20:23:21 #vote last cycle 20:23:36 We are getting enhancement patches on neutron-lbaas. This is going to get ugly with the API move work. 20:23:36 (flavors spec), no response comments from original author 20:23:38 ok, that wa striggered by #link: https://review.openstack.org/#/c/445274/ 20:23:59 m-greene- I think it is a spec without an owner at the moment. 20:24:04 but we need to announce it properly and not pull the rug from people 20:24:07 johnsom: I had to tell you but I agree with rm_work 20:24:31 xgerman Yep. That is why I wanted to talk about the timing. 20:24:46 also are there any more blueprints we failed to mark down 20:24:47 I am happy to send out something saying Pike-1 is it. 20:24:54 +1 20:24:54 o/ 20:24:57 sorry to be late 20:25:28 hey 20:25:32 I think the neutron PTLs have archived any legacy blueprints for neutron-lbaas 20:25:50 I have moved all of the bugs/RFEs over already 20:25:58 diltram: ugh and that gate is voting. this sucks 20:26:14 \o/ our gate is broken again woo 20:26:31 I just want to make sure that we don;t see a feature appear and then somenody points to some bleuprint we ignored 20:26:34 So any objection to sending out a e-mail marking Pike-1 feature freeze for neutron-lbaas? 20:26:44 no, go for it — 20:26:47 nop 20:27:04 xgerman I would point them to contribute the code to Octavia repo. 20:27:10 it seems Heat are the biggest obstacle so ight be worth to reach out to them infromally 20:27:25 It's not like we are halting load balancing work, just shifting the location 20:27:45 yep, but they will whine that we don;t have migration ready, etc. 20:28:14 why heat would want to use any migration scripts? 20:28:23 They can keep using neutron-lbaas and we will still need to handle bugs, it's just new features 20:28:46 yep, I am just playing devil’s advocate 20:28:55 I think it is in reference to the v1 person that missed the memos two years ago.... 20:29:04 :P 20:29:17 I have seen people being concerned about LBaaS V2->Octavia migration 20:29:19 xgerman, is that a another idea for a mascot? :) 20:29:29 HA 20:29:31 lol 20:30:06 macot = ‘groundhog day 20:30:23 where every day I get asked about v1-v2 upgrade 20:30:24 Ok, Let's start the flame wars and mark Pike-1 feature freeze for neutron-lbaas. I will also reach out to kevinbenton 20:30:38 +1 20:31:05 #topic Walmart Act/Act meeting 20:31:33 We had a nice chat/presentation from some folks a Walmart that have done a proof of concept Act/Act implementation 20:31:58 johnsom, did they share the presentation / submited anything else? 20:32:11 they promised to share 20:32:20 They are using a hybrid anycast / resiliant hashing ECMP 20:32:53 The slides they had included a lot of internal stuff, but they will write up a spec with the details 20:33:04 So we can all review and comment 20:33:23 It sounds good though. Looking forward to the spec 20:33:29 +1 20:33:33 +1 20:33:39 they are also adding a BGP soeaker to the amp image 20:33:56 My one concern is we need to land some of the base act/act stuff 20:34:05 Yep, forgot that part. 20:34:19 about act/act I have been told that stick-tables don’t scale 20:34:58 xgerman That is true. The spec calls out they will be grouped 20:35:05 k 20:35:50 Any other comments about the proposal? 20:35:57 Next step is a spec 20:36:25 #topic Open Discussion 20:36:48 ok, we have seen two proposals to extebd the lb create 20:36:56 #link https://review.openstack.org/#/c/445274/ 20:37:33 amnd QoS 20:37:47 #link https://review.openstack.org/#/c/441912/ 20:38:08 I am wondering if we want to keep tham as one-offs or have a more integarted approach 20:39:17 I can see FWaaS or whatever can be dangled on the port in] the future… 20:39:24 diltram: https://review.openstack.org/#/c/446169/ 20:39:31 we put ours up at the same time 20:39:34 Yeah. Personally I don't mind extending the API when it makes sense. 20:39:57 but i realized for round 2 that it isn't quite that simple 20:39:58 diltram: see what i ended up doing 20:39:59 saw it 20:40:04 xgerman Did you have a proposal for a different approach? 20:40:17 rm_work: done the same :P 20:40:21 lol 20:40:30 we talked about “cloning” the port earlier 20:40:42 diltram: no i mean, now 20:40:45 diltram: patchset 2 20:40:48 rm_work: you need to remove also this linux.interface 20:41:02 or expose the port for people to add suff 20:41:22 but even now you can specify the port 20:41:27 diltram: ah _INTERFACE_DRIVER_OPTS could be used directly, got it 20:41:28 so where is the problem? 20:41:50 we don’t really use that port for anyhting 20:41:50 I am not a huge fan of exposing the port and letting end users mess with it in a non-controlled way. It seems like it could break things like failover 20:42:20 on the other hand if we control those things we have to fix stuff when they break us 20:42:27 Like what happened with the DNS being auto enabled on the ports 20:42:35 yeah 20:42:42 rm_work: abandon your patch, we need to merge this one - https://review.openstack.org/#/c/352471/9 20:42:58 ah k finally 20:43:18 wait but that misses a spot T_T 20:43:19 fff 20:43:20 lol 20:43:24 i can fix it 20:43:28 I have no good answer neither it just doesn’t feel like core LB functionality 20:43:34 diltram That won't merge as it's dependent hasn't merged 20:43:36 actually it doesn't do a complete job 20:43:44 johnsom: removed the tag 20:43:57 oh right 20:44:07 nah this depends on ANOTHER patch 20:44:16 xgerman Yeah, but there is overlap. Many LBs also do things like QoS and ACLs 20:44:23 we'll want to merge mine i think and remove that part from this one 20:44:26 degorenko: ^^ 20:44:27 err 20:44:29 diltram: 20:44:47 ok, since we are all distracted by patches should we defer or just deal with the one-offs as they appear 20:45:00 I could see value in being able to accept some of those settings and either use neutron or pass it through to the driver 20:45:28 yep, I like us to be a bit decoupled as well 20:45:57 diltram: yeah this patch is totally different actually 20:45:59 m-greene- What are your thoughts about QoS and ACLs? Is that something you could see implementing in your driver in the future? 20:46:49 Or would you lean towards just using neutron for those? 20:47:32 We might have lost him... 20:47:38 yep 20:47:50 If ACLs ::= security group rules/policies, yes, our customers have interest in us off-loading that from each compute node to an appliance for more performance 20:48:37 that’s more “perimeter defense” stuff.. QoS is more traffic-shaping and I don’t know as much 20:48:53 Ok, good info. 20:49:14 yep, we might need to push the current proposals to delegate the specifics to a driver 20:49:16 that would be a fwaas driver though ;) xgerman was trying to recruit me at PTG 20:49:27 So that leans more towards we have an API for that sort of thing 20:49:40 nah, fwaas is doing it’s thing alright 20:50:02 ACls => L2-L4 tuple, not so much on L7 which already exists in lbaas, right? 20:50:03 johnsom not only an API but also a driver 20:50:22 well, people like to pass in security groups 20:50:24 Yes and yes 20:51:04 pass in , as in attach an object Id ala barbican container ID 20:51:23 yep 20:51:34 I don't like the security group thing. Again, it speaks of trouble. I would lean more towards an ACL api like we have for L7 20:51:56 ok, we can also use Common Classifiers for our ACLs 20:52:05 It would also limit the vendor drivers. 20:52:19 Ha, haven't looked at that stuff in a while 20:52:20 I use that reference becasue SG already exists, and I thought FWaaSv2 was going to supercede SG and combine in higher-level policy abstraction 20:52:23 #link https://review.openstack.org/#/c/333993/ 20:52:36 m-greene correct 20:53:02 yeah, I don’t think we need to re-invent that wheel 20:53:07 Interesting 20:53:54 well, so basically we allow people to pass in a sg-id and we do soemthign meaningful with it or we make them give us their rules in some format 20:54:08 I prefer the former 20:54:17 And what happens when they change it's definition? 20:54:33 then things change 20:54:40 Or can you not change the definition, just make a new one? 20:54:50 in octavia wouldn’t we want the same behavior for SG, barbican and eventually flavor? 20:55:11 octavia download and dump the objects contents into the service def passed to the worker? 20:55:14 yep, that’s why I am bringing that up — we should come up with a party-line 20:55:16 or vendor driver 20:55:42 Right, barbican you can't change the contents, only give us a new ID 20:55:58 Flavor is kind of the same thing, set it once per LB 20:56:01 is the broader request for LBaaS to start enforcing sec policy? 20:56:03 security groups you can delete, add rules, etc. 20:56:10 SG can be updated outside of our knowledge 20:56:15 yep 20:56:20 just like barbi 20:56:28 can 20:56:46 no barbican is create/read - no update 20:56:55 Rigth 20:56:55 not now 20:58:07 I'm not sure either solution solves the one security group request I heard. It was about leveraging some transitive trust to work around some kubernetes issues. 20:58:36 Well, we are about out of time. Let's think about this more and bring it up as a topic again. 20:58:43 ok 20:59:17 Thanks folks for joining and your input. 20:59:28 Chat with you next week or in the channel. 20:59:40 o/ 20:59:42 well this becomes very interesting with containers… LBaaS is traditionally north-south for ingress traffic to a tenant (web app). so sec gropus come in to play for east-west lb between containers within a tenant? 20:59:43 o/ 21:00:03 #endmeeting