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