19:59:58 <sbalukoff> #startmeeting Octavia
19:59:59 <openstack> Meeting started Wed Oct  8 19:59:58 2014 UTC and is due to finish in 60 minutes.  The chair is sbalukoff. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:00 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:02 <openstack> The meeting name has been set to 'octavia'
20:00:06 <sbalukoff> #topic Roll Call
20:00:06 <blogan> hi
20:00:13 <sbalukoff> Hi folks!
20:00:15 <ptoohill> hello
20:00:19 <ajmiller> o/
20:00:24 <TrevorV> o/
20:00:26 <rm_work> o/
20:00:32 <ptoohill> o/
20:00:43 <sbalukoff> As usual, the agenda for today's meeting is here:  https://wiki.openstack.org/wiki/Octavia/Weekly_Meeting_Agenda#Agenda
20:01:13 <sbalukoff> This might be a shorter meeting today (yay!)
20:01:17 <sbalukoff> #topic Update on BP / Gerrit review progress
20:01:19 <johnsom_> Hello
20:01:22 <xgerman> o/
20:01:27 <dougwig> o/
20:01:30 <sballe> o?
20:01:33 <sballe> o/
20:01:47 <blogan> operator-api https://review.openstack.org/#/c/121233/ ready to be reviewed
20:01:49 <tmc3inphilly> Good day
20:02:09 <blogan> though I do need to add more comments
20:02:20 <sbalukoff> blogan's is huge-- but it's the first significant amount of real code for this project.
20:02:23 <sbalukoff> So, huzzah!
20:02:36 <sbalukoff> And yes, we need to get eyes on that.
20:02:46 <sbalukoff> (I'll be working on that tomorrow, blogan... probably all of tomorrow. ;) )
20:02:48 <sballe> blogan:  Great job!
20:02:54 <TrevorV> sbalukoff thinking my repository review isn't significant... thanks bruh, I appreciate that
20:02:54 <xgerman> +1
20:02:56 <johnsom_> Nice
20:02:57 <blogan> yes it is huge, tests end up doing that
20:03:08 <sballe> :-)
20:03:29 <sbalukoff> TrevorV: Sorry-- I didn't mean to disrespect your work, eh.
20:03:40 <blogan> btw I went with functional tests for the API, unit tests with mocks is a pain in the ass with wsme and pecan decorators
20:04:34 <sbalukoff> blogan: I've no doubt it's as long as it needs to be, and I personally dislike having to split these things up if they're all truly related.
20:04:41 <dougwig> you can mock those by monkey-patching
20:04:52 <sbalukoff> I could also use some eyes on this: https://review.openstack.org/#/c/126801/
20:04:54 <rm_work> we'll want unit tests eventually, yes
20:05:01 <rm_work> but functional tests are great too :)
20:05:15 <ptoohill> unit tests are for the devil
20:05:17 <sbalukoff> (It's an initial draft, and I'm expecting to have to change things, especially in light of what comes from later meeting topics.)
20:05:27 <blogan> dougwig: monkey patching would have to be done at hte right time, it was just a nightmare, we can talk about it after
20:05:55 <dougwig> k, no worries.
20:05:57 <sbalukoff> Ok, anyone have anything else they'd like to say about the in progress review stuff?
20:06:20 <sballe> sbalukoff: Can you add the review to: https://etherpad.openstack.org/p/octavia-pending-reviews
20:06:27 <davidlenwell> +1
20:06:31 <xgerman> +1
20:06:33 <sballe> That where I go to get a status on hwta needs my attention
20:06:35 <sbalukoff> sballe: Yep, sorry, hadn't gotten that done yet.
20:06:37 <sballe> s/what
20:06:51 <blogan> but yeah unit tests are not impossible, it just would have added a lot of time and extra work that some poor soul can do after, unless the majority thinks it is really necessary
20:07:23 <sballe> blogan: What are the chances they never get done?
20:07:33 <sballe> because novbody thinks it is fun to do?
20:07:57 <xgerman> yeah, that worries me, too. Tests are always necessary...
20:08:08 <rm_work> I had a question about my CR (https://review.openstack.org/#/c/123492/) -- originally it was supposed to just be stubs apparently, but I have the actual CODE in that review -- is that ok? or were we trying to do a quick pass and merge all the stubs, then come back and merge the code?
20:08:17 <sballe> I agree and they make sure we keep things consistent
20:08:19 <rm_work> (can be dealt with after whatever the current topic is)
20:08:23 <blogan> sballe, xgerman: don't worry ill do it if no one else wants to
20:08:27 <rm_work> (didn't actually mean to hit enter yet)
20:08:35 <davidlenwell> my usually process is write specs then tests then code the api
20:08:43 <sballe> rm_work: Happy to me once in a while
20:08:52 <dougwig> rm_work: it's good either way
20:08:56 <dougwig> unless someone is waiting on you
20:08:59 <rm_work> kk
20:09:02 <sballe> davidlenwell:
20:09:06 <sballe> davidlenwell: +1
20:09:09 <xgerman> davidlenwell you are more disciplined then most
20:09:35 <davidlenwell> xgerman: I'm not saying I don't sometimes just write an api while designing it
20:10:10 <xgerman> :-)
20:10:13 <dougwig> 0.5 is pretty much a learning experience/proof-of-concept. spending more time writing unit tests than doing that research would be counter-productive at this stage.  i don't know about y'all, but i don't expect the first stab at the controller to be the final one.
20:10:17 <dougwig> IMO
20:10:28 <davidlenwell> it really depends on how defined the end goal is
20:10:34 <sbalukoff> dougwig: +1
20:10:34 <sballe> blogan: At this point IMHO we should have unit tests to make sure that pieces aren't breaking. It is less of a problem since you are one of the few writting code right now. But as the group grows it will become a MUST have
20:10:57 <davidlenwell> part of the core concept behind scrum is that you need/want to be able to pivot easily .. if you have a lot of tests that becomes harder to do
20:11:08 <sbalukoff> davidlenwell: It's not as well defined as we'd like, despite months of discussion, design work, etc. Some of the things we're going to do still need to be figured out.
20:11:29 <sbalukoff> And I don't think that's unexpected: After all, we have to be practical in how we approach this, IMO.
20:11:30 <davidlenwell> in those cases I say forgott the tests until they are defined
20:12:29 <sbalukoff> We're still very much at the beginning of code in this project.
20:12:33 <xgerman> well, there is also the argument that people still use some Neutron LBaaS which was meant to be a prototype in prod
20:12:37 <sbalukoff> And pivots are very likely to happen.
20:12:56 <davidlenwell> then keeping the test load lighter makes more sense..
20:13:04 <sbalukoff> xgerman: I have no problem pointing and laughing at people who didn't follow the advice of the people who wrote the code.
20:13:06 <dougwig> i, personally, like just enough unit tests to catch gross import and syntax errors, at a minimum.  but if blogan thinks the payoff on full unit tests isn't there right now, i can see a good argument for not going hog wild.
20:13:13 <davidlenwell> I'm not saying don't have tests.. you need some tests ..
20:13:23 <davidlenwell> dougwig: +1
20:13:32 <xgerman> dougwig +1
20:13:32 <sbalukoff> dougwig: +1
20:13:35 <blogan> sballe: honestly neutron, ironic, and barbican do not have unit tests for their API, they only have functional tests.  Now, obviously that argument is teh same as saying we should do the same wrong thing because other people do it, but just throwing it out there
20:13:39 <sballe> I agree on the pivots. They will happen. dougwig I agree with your comment
20:13:55 <rm_work> well, he said he has functional tests... those count as "some tests" to me
20:14:07 <ptoohill> rm_work +1
20:14:13 <sbalukoff> rm_work: +1
20:14:17 <sbalukoff> Aanyway!
20:14:36 <sbalukoff> The point is: We need people to get their eyes on blogan's gerrit review.
20:14:48 <davidlenwell> tag me in reviews
20:14:54 <sbalukoff> If there are specific things you want tested that aren't, point them out in comments.
20:14:56 <davidlenwell> I'll also try to go out of my way to find them
20:15:12 <TrevorV> davidlenwell just like all the other people that find them ;)
20:15:13 <ptoohill> Doesnt gerrit bot link them here?
20:15:28 <sbalukoff> davidlenwell: This can help: https://review.openstack.org/#/q/stackforge/octavia+status:open,n,z
20:15:41 <ptoohill> or not here, sorry, but openstack-lbaas
20:15:48 <sbalukoff> ptoohill: If you're online to see them, yes.
20:16:03 <ptoohill> Oh, i have bouncer set up, so i see past messages
20:16:14 <davidlenwell> should make a plugin for my irc client that just opens a browser window when it see's one
20:16:15 <ptoohill> forgot, not everyone has one of those fancy things set up
20:16:36 <sbalukoff> Heh!
20:16:46 <sbalukoff> Ok, I think we should move on to the next topic.
20:16:49 <sbalukoff> #topic Floating IPs discussion
20:17:10 <sbalukoff> blogan and ptoohill: Can you summarize your thoughts from the ML discussion?
20:17:23 <ptoohill> Okie, not sure many have looked at the email thread. But i know blogan and dougwig chatted about it a bit and i think we have a temp solution
20:17:40 <sbalukoff> Excellent! Let's hear it!
20:18:00 <ptoohill> The problem is/was that the vip/port is created in the plugin and returned to the user before the drivers get to do anything with it..
20:18:24 <ptoohill> and currently there is no code to actually handle the association of the flip in the plugin
20:19:11 <ptoohill> So, this would mean, if we want to do it on behalf of the user, that the drivers or the plugin would need to be updated to handle this. That way the user can be fed a FLIP
20:19:13 <ptoohill> But
20:19:37 <dougwig> though neutron can still assign flip's to vip ip's.  the table is just stored outside the lbaas db, and not show via the lbaas CLI commands.
20:19:48 <ptoohill> Correct
20:19:55 <ptoohill> which was what i was typing
20:20:20 <dougwig> and i would argue that assignment of flip's to internal ip's should remain a function of neutron, not lbaas, though we can enhance the display/create portions to automate that.
20:20:29 <ptoohill> So, the 'temp' solution would be to let the user associate the vip themselves and they would know what the flip is at that point
20:20:53 <dougwig> and by "the user", it could be a custom UI, or a custom CLI, etc...  doesn't have to be the end customer.
20:20:58 <ptoohill> indeed
20:21:09 <ptoohill> but, this is where the discussion' was supposed to happen
20:21:21 <ptoohill> and, also this solution requires no change at this point
20:21:24 <sbalukoff> What's the "permanent" solution?
20:21:33 <ptoohill> good question
20:22:09 <dougwig> nova has a concept of auto-assigning a flip, and 'nova show' returns associated flips.  i'd suggest a similar model.
20:22:12 <ptoohill> A possible solution, or what we would want, is to associate the flip and return it to the user in the sync part of the api
20:22:32 <sbalukoff> Right. So stated another way, if we were designing this from scratch and could make Neutron do whatever we want, how would we want to handle this?
20:23:17 <dougwig> that doesn't change my answer; not sure about others.
20:23:30 <xgerman> so basically we have to cases:
20:23:41 <xgerman> 1) The user gives us an FLIP and we assign it
20:23:51 <xgerman> 2) We get one ourselves and return to the user
20:24:26 <xgerman> (1) is possible today; (2) needs changes?
20:24:54 <sbalukoff> The user only really cares about the FLIP because that's what they're going to be pointing their DNS entries, etc. at... but otherwise doesn't care how it gets plumbed, etc.
20:24:59 <ptoohill> Its possible today assuming the user makes an additional call to view the flip and its association
20:25:00 <TrevorV> xgerman the problem for (2) is the user gets a response before we're able to get the FLIP and respond.  (if I understand correctly)
20:25:00 <blogan> well 1) is really the user is given a neutron port, and they create their own FLIP and associate it with that neutron port
20:25:10 <ptoohill> xgerman +1
20:25:14 <ptoohill> oh
20:25:18 <ptoohill> i mean TrevorV
20:25:47 <blogan> for 1) neutron lbaas would not know about the FLIP
20:25:53 <dougwig> keep in mind that the api should not be catering to the user, but rather to the operator.
20:25:56 <xgerman> TrevorV that's not a problem. In libra you have to call show on the LB to get the FLIP if you didn't provide one
20:26:18 <sbalukoff> dougwig: Are you talking about the Neutron LBaaS API?
20:26:24 <sbalukoff> Because I thought that's what we were talking about.
20:26:28 <ptoohill> Yes, but the intital response would have the private net vip port IP
20:26:30 <blogan> dougwig: actually I disagree with that, I think a user friendly API should be a goal
20:26:46 <xgerman> blogan +1
20:26:53 <sballe> blogan: +1
20:27:00 <ptoohill> They would have to make addiational calls, that may not show the initial IP we gave them in the response
20:27:22 <dougwig> i think it's up to the operators, horizon, or the CLI, to make higher level operations out of lower-level primitives.  otherwise we risk miring lbaas in floating ip details that should be being handled by the floating ip modules.
20:27:30 <ptoohill> But, yes, this is all possible today assuming we ensure the user handles it
20:27:33 <blogan> but there is a gray area of how much orchestration a service should do and when it should leave it to an actual orchestration layer
20:27:48 <sballe> sbalukoff: I have a hard-stop at 4:30pm (org-wide meeting) so I am going to sync-up with blogan, sbalukoff, etc. and get the diagram updated to reflect the current state and we can discuss it next week. I would like to make sure that as decisions are made we reflect it into this diagram. I had for example no idea that blogan was adding a layer which I
20:27:48 <sballe> didn’t see discussed anywhere.
20:28:20 <sbalukoff> sballe: Your hard stop is in 2 minutes?
20:28:24 <sballe> yes
20:28:32 <xgerman> it's actually a HP hard stop
20:28:33 <sballe> I am already on the other call.
20:28:37 <rm_work> well, this could also be a topic for tomorrow's meeting, more appropriately I think
20:28:40 <sbalukoff> sballe: Unfortunately I'm going to be unavailable next week. But, I can sync up with you in the next couple of days.
20:28:43 <blogan> sballe: i mentioned it barely in a meeting, but yeah it came about late for sure
20:28:45 <rm_work> since it's a neutron-lbaas layer thing
20:28:53 <sballe> sbalukoff: yes let's do that
20:28:54 <sbalukoff> rm_work: Agreed!
20:29:06 <sbalukoff> It's just as much about Neutron LBaaS v2 as it is about octavia.
20:29:12 <sballe> blogan: no problem. we just need to add it to the diagram
20:29:20 <rm_work> hmm
20:29:55 <ptoohill> I think we were ok with assuming the user would handle it for now, but would really like it to be 'automated' however thats going to happen
20:30:28 <ptoohill> Primary issue is returning a vip in the create response that may not work/be used after the LB is created
20:30:35 <dougwig> an optional config setting to automate it would be something that'd i'd certainly support.
20:30:50 <blogan> thats what we figured we woudl do
20:30:55 <sbalukoff> To be honest, I'm a little worried about the semantics of how FLIPs are handled and how they're eventually going to have to work with, say, Octavia v2.0 (ie. active-active topologies). I've been trying to make time to work on diagramming this all out... which I think could be very enlightening to the current discussion.
20:31:01 <dougwig> likewise, we can lookup the mapping and return it in vip show today without much effort.
20:31:03 <sbalukoff> I apologize that I've not been able to bring that to the group yet.
20:31:07 <blogan> or it'd be a flavor thing, though thats still ambiguous
20:31:29 <sbalukoff> s/semantics/specifics/
20:31:35 <xgerman> I think the "lazy" customer sshould bes upported ina ll falvors
20:32:05 <dougwig> i still don't think we're talking customers here.  just who has to do the extra work: neutron or the operator.
20:32:33 <sballe> operator wouldn't that be the user?
20:32:50 <sbalukoff> sballe: Not really.
20:33:03 <sballe> What would be an example?
20:33:09 <sbalukoff> At least, not if I'm understanding dougwig correctly.
20:33:19 <sbalukoff> (which I may not be.)
20:33:19 <sballe> to me the user is the one setting up the lbs.
20:33:28 <sballe> or requesting them
20:33:29 <dougwig> e.g. go buy an instance at rax.  you don't have to ask for a floating ip.  but neutron doesn't automate those.
20:33:42 * sballe on hold getting ready for the org-wide meeting
20:33:58 <johnsom_> Shouldn't we expect that creation is an async operation from the user perspective?  As sbalukoff mentioned, in v2 with active-active I suspect that setup is going to take some time, whether you front the vip with a flip or not.
20:34:13 <rm_work> dougwig: well, we don't have floating IPs yet, so that is part of why :P
20:34:24 <ptoohill> thats sorta the point johnsom_
20:34:28 <rm_work> we used fixed-ips generated via some nova-neutron integration magic
20:34:29 <dougwig> well, yeah, but you do have public vs internal IPs.
20:34:38 <ptoohill> The user will get a privatenet vip instead of the flip in the response
20:36:55 <sbalukoff> I'm not really hearing strong opinions in any particular direction here.
20:37:15 <sbalukoff> And I'm guessing that's because this is a somewhat difficult problem to understand.
20:37:34 <blogan> it is
20:37:34 <sballe> sbalukoff: I agree. I think we'll learn more as we go
20:37:37 <ptoohill> Indeed :/
20:37:42 <blogan> and im sure more surprises will come up
20:38:18 <xgerman> well, it not being synchronous is fine
20:38:23 <sbalukoff> Would it help to actually have someone write down a step-by-step provisioning process (or create a diagram of the same) for each proposed solution?
20:38:57 <sbalukoff> Part of the problem with 2) above is that it seems really nebulous right now to me, and therefore is difficult to have any idea how to compare this practically with 1)
20:39:04 <johnsom_> I plan to do some sequence diagrams as part of the controller work
20:39:08 <sballe> yes. I was looking for the LBaaS API v2 and was trying to do this last week but ran out of time
20:39:34 <blogan> sballe: trying to associate a flip with the neutron vip port?
20:39:43 <sballe> hre is a great free program: https://www.websequencediagrams.com/#
20:39:54 <sbalukoff> ptoohill: Would you be willing to do this? Write either a step-by-step description of the processes or create a diagram for each?
20:40:00 <sballe> blogan: no just what would the step be for a user to ask for a load-balncer
20:40:07 <blogan> ah okay
20:40:52 <sbalukoff> Did we lose ptoohill?
20:40:57 * sballe needs to pay attention to the presentaion. I will catch up with you later
20:41:37 <ptoohill> Im here, sorry, chatting outside of IRC, yea I can write that up
20:41:43 <sbalukoff> Thanks.
20:41:44 <rm_work> we're discussing internally, lol
20:42:03 <TrevorV> sbalukoff, action item him... DO IT
20:42:14 <sbalukoff> #action ptoohill to create step-by-step process description for options for FLIP management.
20:42:22 <rm_work> so, AFAICT we'd need to almost leave it up to the driver layer, because for Octavia, *Octavia* needs to be in control of the FLIP for failover/scaling
20:42:26 <sbalukoff> rm_work: NOT ALLOWED!
20:42:37 <sbalukoff> (you know, since we're all supposed to be talking on IRC. ;) )
20:42:40 <rm_work> T_T
20:42:55 <sbalukoff> rm_work: I suspect that's correct.
20:42:58 <blogan> how else are we going to say bad things about you without fear of your wrath?
20:43:06 <sbalukoff> Ok, I'll know.
20:43:26 <ptoohill> O.O
20:43:31 <dougwig> rm_work: there is nothing preventing us from putting flip interfaces into octavia's network/neutron interface layer.  it certainly does not have to be in the driver only.
20:43:31 * ptoohill scared now
20:43:36 <sbalukoff> Ok, so... let's continue this discussion once we have more concrete process to evaluate, eh.
20:43:47 <dougwig> in fact, for L3 active:standby, it'll be required.
20:43:58 <sbalukoff> dougwig: +1
20:44:19 <sbalukoff> Ok, the next agenda item is to discuss sballe's diagram.
20:44:28 <rm_work> but sballe just left T_T
20:44:31 <sbalukoff> #topic Discuss sballe's LBaaSv2 workflow diagram: https://region-a.geo-1.objects.hpcloudsvc.com/v1/52059731204378/LBaaS/LBv2_workflow.GIF
20:44:35 <rm_work> we maybe should have done this first
20:44:37 <sbalukoff> I think we can still discuss some of that...
20:44:45 <sbalukoff> I think she was interested in knowing what's incorrect / missing.
20:44:51 <rm_work> right
20:44:56 <sbalukoff> rm_work: Yeah, I didn't know she'd be leaving.
20:44:59 <sballe> I would liek to update it to reflect the current status
20:45:05 <blogan> i commented earlier on it, i think she got it
20:45:09 <rm_work> so my comment earlier was about the second and third to last elements
20:45:10 <sballe> yep.
20:45:18 <rm_work> but yeah I think we all pretty much agreed
20:45:30 <sbalukoff> Yeah on that:
20:45:49 <sballe> sbalukoff: I'll reach out to you tomorrow to get your input
20:45:51 <sbalukoff> rm_work: I'm generally in agreement that the thing controlling the API and the thing controlling haproxy might not be the same thing.
20:46:02 <rm_work> hmm
20:46:11 <rm_work> so TWO processes running on the Amphora?
20:46:15 <rm_work> how do THEY communicate?
20:46:19 <sbalukoff> There are potentially quite a few components "doing stuff" on the amphora...
20:46:31 <rm_work> does the agent need an API so the API can contact it? do we need rabbitMQ on the Amphora? T_T
20:46:34 <blogan> the handler layer I talked about can be discussed here, to see if people dont think it is needed or if it is
20:46:44 <sbalukoff> rm_work: I don't think so.
20:46:51 <rm_work> (you can tell i think both of those are ridiculous)
20:47:02 <sbalukoff> blogan: Let's get to that in a minute.
20:47:14 <blogan> sure
20:47:16 <rm_work> so, the only case that having two separate processes running *on the amphora* is if there is zero intercommunication between the two and they are completely autonomous
20:47:23 <rm_work> which is not what the diagram shows right now :p
20:47:32 <sbalukoff> rm_work: I'm thinking that will largely be the case.
20:47:52 <sbalukoff> rm_work: The thing emmitting health status information doesn't need to talk to the thing handling the API
20:48:00 <rm_work> so then, the diagram needs to update to not show them communicating
20:48:12 <sbalukoff> All it needs to do is discover when a config has changed (which it can do on the fly) and alter its output accordingly.
20:48:21 <sbalukoff> rm_work: Aah! Yes, I agree.
20:48:23 <rm_work> basically, the  API talks directly to ha-proxy and the Agent talks BACK to the controller / operator api
20:48:30 <xgerman> the health thing should know when the api thing restarts stuff
20:48:41 <sbalukoff> rm_work: Yep.
20:48:56 <rm_work> so, depicting THAT correctly would be my only concern so far
20:48:57 <sbalukoff> xgerman: Fine, then it can look at process timestamps or something.
20:49:24 <xgerman> processes die unplanned, too, just saying
20:49:25 <sballe> rm_work: Is the "API talks directly to ha-proxy" only for 0.5? To me we need a separation there in the future
20:49:43 <sbalukoff> xgerman: And the healthcheck thingy should be able to detect that. :)
20:49:49 <xgerman> yep
20:50:01 <sbalukoff> sballe: You're in another meeting! Go away! ;)
20:50:10 <sbalukoff> sballe: Seriously, though: Why?
20:50:17 <sballe> sbalukoff: I can't since you are discussing the diagram
20:50:30 <sbalukoff> sballe: Oh! Ok-- we can stop discussing that if you'd like.
20:50:45 <sballe> sbalukoff: I am assumign eventually we'll support other software LB than haproxy
20:50:48 <sbalukoff> (If you'd rather be able to devote your whole attention to it.)
20:51:08 <blogan> won't that just be another image?
20:51:12 <blogan> or another amphora image
20:51:15 <sbalukoff> sballe: We certainly will. And that will require its own amphora driver and own amphora type.
20:51:19 <rm_work> sballe: can you link to the websequencediagram page with the source for that?
20:51:21 <sbalukoff> blogan: +1
20:51:27 <dougwig> sbalukoff: +1
20:51:30 <dougwig> blogan: +1
20:52:01 <sbalukoff> Behind the amphora driver, we can and will be haproxy-specific.
20:52:17 <dougwig> it's important to separate interfaces/architecture with the specific implementation, and IMO, the architecture stops at the interface to the amphora.
20:52:33 <sbalukoff> dougwig: +1
20:52:38 <sballe> dougwig ok.
20:52:46 <xgerman> well, people might want to "reuse" the haproxy driver for something else...
20:53:11 <xgerman> but they are on their own
20:53:16 <sbalukoff> xgerman: Sure, use it as a template. That's fine. But again, there's no reason to make the haproxy amphora handle anything other than haproxy.
20:53:32 <xgerman> yep, exactly
20:53:41 <sbalukoff> Ok!
20:54:21 <rm_work> sballe: I meant the Amphora-side API
20:54:24 <sbalukoff> Anyway... We're nearly out of time...  I will be out of the office next week, but y'all should discuss this further then too.
20:54:54 <sbalukoff> ok, One last topic
20:54:57 <sbalukoff> #topic Facilitator for 2014-10-15 meeting
20:55:06 <sbalukoff> I'm gone all next week. Who wants to run the meeting?
20:55:19 <sbalukoff> (And send out reminders, etc.)
20:55:19 <blogan> ill be here
20:55:23 <blogan> oh no
20:55:27 <sbalukoff> Haha!
20:55:35 <sbalukoff> Too late!
20:55:45 <blogan> well ill do it if no one else wants it
20:55:53 <dougwig> ditto
20:56:07 <blogan> dougwig you already do the neutron lbaas one
20:56:42 <dougwig> i'm not saying i like running meetings, and you've already called dibs.
20:56:42 <sbalukoff> #action blogan and dougwig to run next week's Octavia meeting
20:56:57 <sbalukoff> Ok!
20:57:00 <xgerman> joint meeting ;-)
20:57:04 <sbalukoff> #topic Open Discussion
20:57:18 <sbalukoff> Anyone have anything else to discuss in the last 2 minutes?
20:57:19 <dougwig> if you've got items for the neutron lbaas meeting, please edit: https://wiki.openstack.org/wiki/Network/LBaaS
20:57:35 <blogan> the handler layer
20:57:41 <sbalukoff> dougwig: Thanks for the reminder, eh!
20:57:46 <blogan> between octavia api and controller
20:57:55 <sbalukoff> Oh crapsticks.
20:57:59 <blogan> since 0.5 is not going ot have a queue, we will send requests straight to controller
20:58:03 <sbalukoff> Sorry, I forgot to address that.
20:58:08 <blogan> 1.0 will have a queue so we'll need to send it to the queue
20:58:17 <TrevorV> blogan I can't say we have enough time to seriously address this...
20:58:20 <sbalukoff> blogan: And your idea is to have a 'handler' which will eventually go to a queue?
20:58:37 <dougwig> let's punt this to the channel?
20:58:38 <blogan> the handler is essentially an abstraction layer taht we can swap out each functionality
20:58:41 <blogan> okay
20:58:46 <dougwig> unless this channel isn't booked now.
20:58:48 <TrevorV> si dougwig
20:58:59 <TrevorV> Might as well migrate (to be on the safe-side)
20:59:02 <blogan> regular channel is fine
20:59:04 <sbalukoff> Yeah, punt to channel, then discuss whatever we come up with at next week's meeting.
20:59:43 <xgerman> bye
20:59:49 <sbalukoff> (Mostly to respect those who might have other things they need to get to immediately.)
20:59:56 <sbalukoff> Yep, thanks for coming, folks!
20:59:58 <dougwig> bye
20:59:59 <TrevorV> \o
21:00:01 <sbalukoff> #endmeeting