20:00:14 <blogan> #startmeeting octavia
20:00:15 <openstack> Meeting started Wed Oct 15 20:00:14 2014 UTC and is due to finish in 60 minutes.  The chair is blogan. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:17 <ptoohill> o/
20:00:19 <openstack> The meeting name has been set to 'octavia'
20:00:20 <TrevorV> o/
20:00:25 <johnsom> o/
20:00:27 <blogan> #topic roll cal
20:00:29 <blogan> #topic roll call
20:00:33 <rohara> o/
20:00:36 <jorgem> Alo everybody!
20:00:41 <ptoohill> hello
20:00:53 <blogan> sbalukoff is not here this week so im the poor sap who will be running this
20:01:05 <jorgem> interim PTL you say?
20:01:17 <sballe> o?
20:01:18 <johnsom> Thanks blogan
20:01:20 <dougwig> despot
20:01:23 <sballe> o/
20:01:25 <blogan> more like a coup de ta
20:01:30 <davidlenwell> o/
20:01:33 <sballe> :)
20:02:21 <TrevorV> coup d'état
20:02:22 <blogan> i created an agenda ad hoc so if anyone wants to add something we can talk about it at the end
20:02:23 <TrevorV> lulz
20:02:26 <TrevorV> it copied that way
20:02:27 <blogan> https://wiki.openstack.org/wiki/Octavia/Weekly_Meeting_Agenda
20:03:07 <ptoohill> FLIP talks, if other concerned parties are here can happen as last topic
20:03:18 <blogan> #topic Neutron LBaaS FLIP Update
20:03:22 <ptoohill> lel
20:03:24 <johnsom> Just that RackSpace has two reports for the week in the standup etherpad.  Here I thought it was our company splitting....
20:03:36 <sballe> lol
20:04:21 <blogan> lol johnsom, i think i put that first copy in there last week....apparently i was doing something stupid
20:04:44 <blogan> anyway FLIP topic
20:04:52 <ptoohill> I don't believe the others that were responding to the email threads are here. But they have brought up some additional ideas about how to handle/deal with floating ips that we are still discussing. There has not yet been a solidified agreement as of yet.
20:05:06 <blogan> been a long email chain on the ML about it, people might need some time to get caught up on it
20:05:12 <ptoohill> indeed
20:05:34 <johnsom> Yeah, it has been a busy week, so I am not caught up
20:05:39 <blogan> ptoohill would you agree that the current plan to just have the user associate the FLIP to the vip port works for now and how to implement the autoallocation of the FLIP can wait until later?
20:05:50 <ptoohill> Agreed
20:06:11 <johnsom> Later like v1.0?
20:06:14 <ptoohill> This will require additional user interaction, but no additional work on our behalf.
20:06:25 <ptoohill> Most likely
20:06:51 <blogan> johnsom: well this would be more on the Neutron LBaaS side, so I'd say later as a feature to go into Neutron LBaaS along with the octavia driver
20:06:52 <johnsom> Yeah, I can agreed that it can hold for v1.0 time frame
20:07:14 <johnsom> Yep
20:07:19 <ptoohill> Well, thats where some of the talks are leading though.
20:07:41 <ptoohill> Vijay brought up having the octavia controller handle the creation/updates for flips
20:08:12 <blogan> yeah but that has other issues when neutron lbaas is being used as a frontend
20:08:14 <ptoohill> Though, this idea is being discussed right now and dont have much more info for the tiem being
20:08:20 <ptoohill> agreed
20:08:29 <blogan> so yeah everyone who has an opinion on it or wants more info, read the ML thread
20:08:36 <ptoohill> ^^
20:08:40 <sballe> ok
20:08:43 <dougwig> I think we pull too much into Octavia, in general.
20:08:51 <johnsom> The controller seems like the logical place, we would just have to defer giving the FLIP to the user
20:08:52 <sballe> dougwig: +1
20:09:36 <ptoohill> There is definately good reasons for having it there, one is during the HA handling. But again, this is still in 'early' discussion and input on the ML is crucial
20:09:58 <johnsom> ptoohill: +1
20:09:59 <ptoohill> pinged a user or keyword
20:10:02 <rohara> ptoohill: +1
20:10:48 <sballe> ptoohill: So are you thinking that the controller will calle the Networkign Driver which will call Neutron, etc
20:10:48 <dougwig> Ha fip handling is a good use case.  But does not mean that all fip handling should be pulled in
20:11:14 <ptoohill> sballe, that is indeed the idea from what i gather.
20:11:27 <ptoohill> dougwig, what would be 'all'?
20:11:33 <blogan> sballe: if octavia were to do its own flip allocation then yeah that would happen
20:11:52 <sballe> blogan: I am not sure we want that right?
20:12:08 <rohara> does this mean we'll have standy octavia instances for HA that just need a FLIP associated to go active?
20:12:42 <blogan> sballe: do you prefer the scenario where a user creates their own flip and associates it with a port? or you prefer neutron lbaas to do the flip allocation?
20:13:11 <ptoohill> rohara, that's a good question. That depends if we are having active-active set up, then associating a flip is all that is needed for it to go active.
20:13:47 <rohara> ptoohill: right. i like that approach.
20:15:13 <blogan> to me the right steps are 1) only allow user to associate flip to neutron lbaas vip port 2) neutron lbaas auto allocates flip and associates on behalf of user 3) investigate whether we want this in Octavia
20:15:37 <blogan> 2 being configurable in neutron lbaas
20:16:24 <blogan> anyone disagree?
20:16:51 <ptoohill> Going forward that sounds like a good plan.
20:17:04 <dougwig> +1
20:17:07 <blogan> okay moving on to next topic then
20:17:16 <blogan> #topic Reviews Needing Attentions
20:17:44 <blogan> #link https://review.openstack.org/#/c/127337/
20:17:52 <blogan> sballe's Workflow diagram
20:17:55 <rm_work> #link https://review.openstack.org/#/c/127353/
20:17:58 <rm_work> ^^ possibly interesting
20:18:42 <rm_work> though as blogan points out, probably more relevant to neutron-lbaas
20:19:06 <blogan> yeah you've lost your link permissions
20:19:14 <sballe> blogan: I will work on fixing them this weekend. I have been traveling
20:19:30 <blogan> sballe: np, i just wantedt o get some attention on it so others take a look
20:19:35 <sballe> thanks
20:19:41 <blogan> also sbalukoff's amphora api spec
20:19:43 <blogan> #link https://review.openstack.org/#/c/126801/
20:19:48 <blogan> taht needs some eyes as well
20:20:04 <blogan> of course he's out this week so he won't be able to respond until he gets back
20:20:24 <davidlenwell> I'm in the middle of reviewing that one right now.. he's asked me to actually do the coding for it.. so I'm trying to really think it through and point out anything that is ambigous
20:20:41 <blogan> haha davidlenwell, you fell into his trap
20:21:04 <davidlenwell> well .. i also work with him and have been asked to make this a priority
20:21:12 <davidlenwell> but yes
20:21:47 <rm_work> http://i3.kym-cdn.com/photos/images/facebook/000/001/384/Atrapitis.gif
20:21:54 <ptoohill> :P
20:22:24 <davidlenwell> lol
20:22:34 <blogan> any other reveiws people want attention on?
20:23:21 <blogan> okay moving on
20:23:29 <blogan> #topic Usage requirements
20:23:34 <jorgem> I'll take this one
20:23:38 <blogan> some of you may remember jorgem
20:23:46 <blogan> he's back from management hell
20:23:49 <jorgem> What is Octavia again? lol jk
20:24:17 <jorgem> I will probably add this to the ML but I have some ideas for usage as I am currently building out usage requirements with Tom
20:24:52 <jorgem> Since we are planning on using TCP, HTTP based protocols I wanted to entertain the idea of capturing logs to accurately record usage
20:25:15 <blogan> do we ever plan on support UDP load balancing? or is that a running joke?
20:25:17 <jorgem> I wanted to do this on our internal LBaaS product but we offer UDP which like 2 people use
20:25:26 <jorgem> so I couldn't do it
20:25:39 <jorgem> Using connection logs has other advantages too
20:26:10 <ptoohill> I thought some were quite serious about supporting UDP.
20:26:38 <jorgem> such as 1) Accurate recording of inbound and outbound traffic 2) Accurate assessment of concurrent connections, etc. 3) Serves as a debugging aid ...
20:26:38 <blogan> it always feels like a joke, but haproxy doesn't even support it
20:27:13 <jorgem> 4) Mitigates uncertainty into capacity management since every lb will have connection logging on by default
20:27:26 <ptoohill> Agreed, and that's correct, we would have to use other tools to accomplish it.
20:27:34 <jorgem> Anyways, now that I'm typing furiously I think this is better for the ML
20:27:40 <blogan> lol
20:27:43 <blogan> yes probably
20:27:51 <TrevorV> We could send UDP over TCP right? right?... guys?
20:28:09 <jorgem> TrevorV: negative
20:28:24 <rohara> UDP healthchecks are a pain
20:28:26 <jorgem> UDP is non-realiable TCP is
20:28:36 <blogan> sballe, johnsom: do you know exactly what usage requirements you have?
20:28:48 <johnsom> Interesting idea, I am just wondering about approaches to handle the log processing load
20:28:50 <blogan> as in what metrics you need to capture, how often, etc
20:28:51 <jorgem> This model only works with protocols that allow connection  logging so UDP is out of the question.
20:29:13 <jorgem> We don't have to perform a map-reduce or anything since logs will be isolated per lb
20:29:16 <dougwig> man, you guys are a bunch of udp haters.
20:29:19 <dougwig> :)
20:29:21 <jorgem> hehe
20:29:29 <jorgem> if we do want UDP this won't work
20:29:35 <jorgem> at least for UDP lbs
20:29:40 <blogan> dougwig: maybe you should marry udp if you love it so much
20:29:54 <dougwig> i embrace the uncertainty.
20:29:58 <jorgem> I've done several usage gathering iterations and this is by far the simplest and most accurate
20:30:09 <davidlenwell> +1 for embracing the uncertainty
20:30:34 <blogan> but can the large load this will incur be handled easily?
20:30:36 <jorgem> anyways, let's debate this on the ML. I just wanted to get it out there and see if there were any immediate objections
20:30:45 <johnsom> I have not yet put a lot of thought into the usage requirements.  There has been some talk about ceilometer being the end destination, but not much about collection.
20:31:13 <jorgem> correct, I think the end desitination will be, dare I say it, configurable.
20:31:20 <blogan> johnsom: wouldn't you need something similar to what libra does?
20:31:21 <johnsom> Someone here had talked about collecting inbound/outbound from iptables
20:31:32 <blogan> sbalukoff was i believe
20:31:53 <jorgem> That's one way but you would have to poll I think
20:32:00 <jorgem> polling == complex
20:32:20 <jorgem> doable but logs is waaaaaay easier
20:32:38 <johnsom> Being new to the group, I tend to be "legacy" free when it comes to libra
20:32:47 * TrevorV thinks the more a's you use the more accurate the statement becomes
20:33:04 <blogan> johnsom: ah fresh mind
20:33:27 <blogan> jorgem: what if a user disables logs?
20:33:41 <jorgem> glad you asked blogan.
20:33:45 <jorgem> I
20:34:04 <jorgem> I'm thinking that we just don't send them to swift in that case but keep them going on behind the scenes
20:34:11 <jorgem> for the other reasons I stated
20:34:36 <jorgem> operations will like to see logs in order to investigate problems
20:34:43 <rm_work> can't we get inbound/outbound from... neutron?
20:34:59 <jorgem> I'm talking apache style logs
20:35:06 <jorgem> or some other format
20:35:29 <johnsom> I had been thinking about "operator" logs vs. "customer" logs.  I.e. security logs, etc. from the Amphora
20:36:03 <jorgem> Some people might want to charge separately for headers and some may not
20:36:15 <jorgem> This would make it easy to capture that and leave it to the operator to decide
20:36:21 <ptoohill> but on rm_work's point, neutron would have the data of traffic passing through the network. assuming the do actually keep track of all the stats we need. Otherwise we would need to augment it
20:36:24 <blogan> well I think we can all agree this needs more discussion on the ML
20:36:34 <jorgem> correct.
20:36:37 <blogan> so jorgem, make a thread
20:36:43 <johnsom> Yes, but good topic
20:36:52 <jorgem> #action Jorge to start thread on usage requirements
20:37:04 <blogan> moving on
20:37:10 <blogan> #topic progress reports
20:37:20 <blogan> so I know we have the weekly ehterpad, that I apparently messed upa  bit
20:37:42 <blogan> but I'm just curious if there are any issues with any bps that have assignees
20:38:10 <blogan> sot eh operator-api one trevor and I ahve been working on is almost done, but some issues need to be ironed out
20:38:26 <rm_work> I'm about to start on integrating Barbican with Octavia, assuming that's in 0.5, otherwise I'll wait a bit :P
20:38:28 <blogan> sbalukoff has the appliance-api BP which he has a spec out for that was linked above
20:38:58 <johnsom> Until this week I had been making progress on a first draft for the controller spec.  I want to have something to throw out there and catch arrows while I code on the image build scripts.
20:39:13 <blogan> arrows in the knee?
20:39:59 <johnsom> Among other places I am sure....
20:40:02 <blogan> johnsom: i didnt include the controller bp because it is blocked by many sub components, so i figured it'd be a while anyway
20:40:36 <johnsom> Yeah, but I think there were be a lot of discussion so having a starting point is probably good.
20:40:46 <blogan> definitely
20:41:07 <blogan> how is the base image coming along?
20:42:15 <johnsom> I have done some experimental images and have a good line of sight on the code.  I just prioritized a first draft of the controller spec.
20:42:30 <blogan> okay cool, just wanted to get an idea
20:42:38 <johnsom> If it is a blocker, I can re-order
20:43:03 <blogan> btw for everyone, don't be afraid to put experimental code in gerrit as a WIP, i think that is a good chance for everyone to look at the code and give good feedback
20:43:06 <rm_work> I think everyone is essentially going to need to develop their own base images anyway...
20:43:21 <blogan> i think a lot of people see WIPs as reviews that don't need eyes, but I think they should be looked at as much as possible
20:43:33 <johnsom> Al on our team also is almost done with a first draft of his spec.  Has been moving this week
20:44:05 <blogan> rm_work: yes but getting something we can actually run as a test deploy will be a big win, even if we at RAX will be using a different image
20:44:21 <blogan> johnsom: thanks for the updates
20:44:22 <rm_work> yeah I guess a "devstack compatible" base image
20:44:23 <johnsom> rm_work: Agreed, but I hope these scripts will make a nice baseline for customization and testing
20:44:45 <blogan> dougwig: any update on the networking bps?
20:46:47 <blogan> i think he may be afk
20:47:11 <blogan> #action dougwig give update on networking driver
20:47:18 <blogan> #topic open discussion
20:47:45 <blogan> anything anyone wants to talk about or just end meeting?
20:48:25 <blogan> im going to take silence as end meeting
20:48:31 <TrevorV> too soon
20:48:33 <TrevorV> wait longer
20:48:36 <blogan> no
20:48:37 <rm_work> lol
20:48:39 <jorgem> wait!
20:48:40 <TrevorV> people can't all type as fast as we do
20:48:46 <jorgem> ok I'm done
20:48:56 <blogan> 3
20:48:58 <blogan> 2
20:49:00 <rm_work> 7
20:49:00 <blogan> 1
20:49:02 <rm_work> 4
20:49:02 <blogan> #endmeeting