| *** dboik has joined #openstack-lbaas | 00:01 | |
| *** dboik has quit IRC | 00:05 | |
| *** VijayB_ has quit IRC | 01:09 | |
| *** TrevorV_ has joined #openstack-lbaas | 01:19 | |
| *** jorgem has joined #openstack-lbaas | 01:39 | |
| *** jorgem has quit IRC | 01:53 | |
| *** fnaval has quit IRC | 01:58 | |
| *** woodster_ has quit IRC | 02:21 | |
| *** ajmiller_ has quit IRC | 02:52 | |
| *** fnaval has joined #openstack-lbaas | 03:00 | |
| *** fnaval has quit IRC | 03:07 | |
| *** IZebra has joined #openstack-lbaas | 03:19 | |
| *** TrevorV_ has quit IRC | 03:49 | |
| openstackgerrit | Brandon Logan proposed a change to stackforge/octavia: Implementing simple operator API https://review.openstack.org/121233 | 03:51 |
|---|---|---|
| *** ptoohill-oo has quit IRC | 03:53 | |
| *** ptoohill-oo has joined #openstack-lbaas | 03:59 | |
| *** sbfox has joined #openstack-lbaas | 05:08 | |
| *** HenryG_ has joined #openstack-lbaas | 05:29 | |
| *** HenryG has quit IRC | 05:30 | |
| *** ksamoray has joined #openstack-lbaas | 05:30 | |
| openstackgerrit | Stephen Balukoff proposed a change to stackforge/octavia: Specification of reference haproxy amphora API https://review.openstack.org/126801 | 05:44 |
| *** rm_you| has joined #openstack-lbaas | 05:56 | |
| *** ksamoray has quit IRC | 05:58 | |
| *** rm_you|wtf has quit IRC | 06:00 | |
| *** ksamoray has joined #openstack-lbaas | 06:02 | |
| *** ksamoray has quit IRC | 06:12 | |
| *** sbfox has quit IRC | 06:13 | |
| *** sbfox has joined #openstack-lbaas | 06:14 | |
| *** ksamoray has joined #openstack-lbaas | 06:20 | |
| *** sbfox has quit IRC | 07:14 | |
| *** jschwarz has joined #openstack-lbaas | 07:30 | |
| *** Krast has joined #openstack-lbaas | 07:38 | |
| *** Krast has quit IRC | 08:52 | |
| *** Krast has joined #openstack-lbaas | 09:01 | |
| *** Krast has quit IRC | 09:04 | |
| *** amotoki has joined #openstack-lbaas | 09:05 | |
| *** Krast has joined #openstack-lbaas | 09:05 | |
| *** jschwarz has quit IRC | 10:17 | |
| *** Krast has quit IRC | 10:22 | |
| *** ksamoray has quit IRC | 10:31 | |
| *** jschwarz has joined #openstack-lbaas | 10:39 | |
| IZebra | Hi all | 10:50 |
| *** IZebra has quit IRC | 10:51 | |
| *** jroyall has joined #openstack-lbaas | 10:57 | |
| *** openstack has joined #openstack-lbaas | 14:13 | |
| sballe | sbalukoff: blogan I created this diagram to show the LBaaS V2 flow. It is far from complete but I wanted to udnerstand where we still had gaps in our blueprints. https://region-a.geo-1.objects.hpcloudsvc.com/v1/52059731204378/LBaaS/LBv2_workflow.GIF | 14:16 |
| sballe | Last I looked it looked like the Amphora agent is still missing from the blueprint list: https://blueprints.launchpad.net/octavia. I am happy to add it. Let me know | 14:19 |
| ptoohill | Mornin' | 14:23 |
| sballe | Hey | 14:23 |
| *** ksamoray has joined #openstack-lbaas | 15:08 | |
| *** ksamoray has quit IRC | 15:13 | |
| *** sbfox has joined #openstack-lbaas | 15:31 | |
| *** ksamoray has joined #openstack-lbaas | 15:34 | |
| rm_work | ooo, fancy diagram | 15:51 |
| rm_work | Amphora API / Amphora Agent -- which is actually *in* the amphora? both? | 15:53 |
| *** ksamoray has quit IRC | 15:57 | |
| sballe | rm_work: thanks :) | 15:58 |
| sballe | yes that's what I was assuming. I think thta sbalukoff is now calling te AMphora-API for appliance API | 15:59 |
| sballe | Once I know I have it right I'll try to redo it with some boundaries so we can show what's in the controller and what is in Amphora, etc. | 15:59 |
| rm_work | yeah | 15:59 |
| rm_work | just not clear on why the two are separate things, if they're both internal to the amphora | 16:00 |
| rm_work | seems like just a single layer to me | 16:00 |
| sballe | they could be the same. I just saw a rest interface on one side and an agent to forward and process requests. | 16:01 |
| rm_work | unless it's just a logical separation somehow? because I'd assume the code would be a single entity I believe | 16:01 |
| rm_work | hmm | 16:01 |
| rm_work | at least the way i'm imagining it implemented, the API code that's listening would be a simple (probably Pecan to match our frontend) app that listens for configs and puts them in place when it gets one | 16:03 |
| rm_work | I guess there's a heartbeat on that side too? | 16:03 |
| rm_work | is that where the agent comes in? | 16:04 |
| rm_work | I guess I'd assume it would go "Amphora API -> ha-proxy", and "Amphora Agent -> Operator API" or something | 16:05 |
| rm_work | essentially "Amphora API" is an outside-in service (listening only) and "Amphora Agent" is an inside-out service (sending data only) | 16:06 |
| rm_work | but I need to re-read the 1.0/2.0 spec today | 16:06 |
| rm_work | otherwise it looks exactly like my current understanding | 16:07 |
| rm_work | blogan: did you look at that diagram yet? | 16:07 |
| *** fnaval has joined #openstack-lbaas | 16:07 | |
| *** markmcclain has quit IRC | 16:09 | |
| *** amotoki has quit IRC | 16:09 | |
| *** german_ has joined #openstack-lbaas | 16:13 | |
| sballe | sorry just had a repairman come and look at my oven. | 16:14 |
| sballe | Yes we need something to do heatbeats, wake up of controller, etc... | 16:16 |
| sballe | I just wanted to do a diagram so we can talk about the gaps and maybe the peice we do not understand well yet | 16:16 |
| *** woodster_ has joined #openstack-lbaas | 16:16 | |
| sballe | We could maybe talk about it at the Octavia meeting today | 16:17 |
| rm_work | yeah, possibly it is a problem with my understanding and not the diagram :P\ | 16:29 |
| rm_work | we'll discuss | 16:29 |
| *** sbalukoff has quit IRC | 16:32 | |
| *** amotoki has joined #openstack-lbaas | 16:36 | |
| TrevorV | dougwig you around? | 16:51 |
| dougwig | yes | 16:52 |
| dougwig | TrevorV: yes, what's up? | 16:53 |
| TrevorV | I had to switch to a different computer at work, and I'm getting a tox error including "dot"... sphinx.errors.SphinxWarning: WARNING: dot command 'dot' cannot be run (needed for graphviz output), check the graphviz_dot setting | 16:56 |
| TrevorV | Is it a requirements failure or something here? | 16:56 |
| TrevorV | I remember having this issue before and couldn't remember how to fix it, thought I'd ask you | 16:56 |
| TrevorV | dougwig I think rm_work just helped me out | 16:58 |
| rm_work | yeah just needed to install graphviz | 16:58 |
| openstackgerrit | Trevor Vardeman proposed a change to stackforge/octavia: Implementing simple operator API https://review.openstack.org/121233 | 17:01 |
| *** xgerman has joined #openstack-lbaas | 17:09 | |
| *** amotoki has quit IRC | 17:11 | |
| *** german_ has quit IRC | 17:11 | |
| *** HenryG is now known as HenryG_afk | 17:20 | |
| *** sbfox has quit IRC | 17:26 | |
| *** markmcclain has joined #openstack-lbaas | 17:30 | |
| *** sbalukoff has joined #openstack-lbaas | 17:31 | |
| *** VijayB has joined #openstack-lbaas | 17:31 | |
| sbalukoff | Hi folks! | 17:33 |
| *** VijayB has quit IRC | 17:33 | |
| sbalukoff | sballe: I'll check that out in a minute. | 17:33 |
| *** VijayB_ has joined #openstack-lbaas | 17:33 | |
| sbalukoff | Does anyone have anything they'd like added to the agenda today? (I've only got a couple small things, so it might be a short meeting, eh.) | 17:34 |
| dougwig | i think brandon and ptoohill wanted to talk about floating ups. | 17:35 |
| dougwig | ips | 17:35 |
| sbalukoff | Ok, sounds good. | 17:35 |
| sballe | sbalukoff: I would like to talk about the diagram and make sure we agree on where things aren't 100% thought out and see if we have gaps: https://region-a.geo-1.objects.hpcloudsvc.com/v1/52059731204378/LBaaS/LBv2_workflow.GIF | 17:37 |
| sbalukoff | sballe: Sounds good. | 17:37 |
| sballe | I'll rework it based on our comments but just so we know where we are at | 17:38 |
| sbalukoff | Cool. I've added that to the agenda. | 17:38 |
| sballe | thanks BTW short meetings are good :) | 17:39 |
| sbalukoff | I totally agree there! | 17:41 |
| sbalukoff | Also, yes, I consider the haproxy amphora API and agent to essentially be the same thing (or rather probably the same couple of people will be working on them) | 17:43 |
| *** HenryG_afk is now known as HenryG | 17:44 | |
| sbalukoff | The set of scripts that run on the amphora will probably be more than a single agent (what with having to emit regular stats updates and whatnot), but the part that powers the API that lives on the amphora is definitely a part of that. | 17:44 |
| sbalukoff | rm_work and sballe: If we want to indicate that they're separate entities on the amphora, I have no problem with that, though I imagine they'll probably be sharing some code. | 17:46 |
| sballe | We agree. | 17:46 |
| blogan | sballe: I've added a layer between the operator API and controller, im calling it a handler right now | 18:01 |
| blogan | the 0.5 handler will just send requests directly to the controller, a new handler will be created to send requests to a queue | 18:02 |
| blogan | for 1.0 | 18:02 |
| blogan | sballe: also the operator API will access the DB as well | 18:03 |
| blogan | sballe: I haven't thought about it much so I could be wrong, but will the controller amphora driver have db access? or will the controller do that? | 18:06 |
| rm_work | dougwig: can you mark https://review.openstack.org/#/c/123492/ as WIP again? | 18:15 |
| rm_work | hey dougwig, for usage on TLSInfo | 18:18 |
| rm_work | dougwig: I'm tempted to move it from being a big collection of static methods, to being an actual instantiated object | 18:18 |
| rm_work | so the usage would be less like A and more like B in the thing i'll link in a sec | 18:18 |
| rm_work | err also, considering moving from CONTAINER_ID to CONTAINER_REF and parsing the barbican endpoint out of that <_< | 18:21 |
| *** sbfox has joined #openstack-lbaas | 18:25 | |
| *** sbfox has quit IRC | 18:26 | |
| *** mlavalle has joined #openstack-lbaas | 18:27 | |
| rm_work | dougwig / sbalukoff / blogan / ptoohill: http://pastebin.com/kkAXxZar | 18:28 |
| rm_work | xgerman: ^^ | 18:28 |
| rm_work | which do you guys prefer? | 18:28 |
| rm_work | err | 18:29 |
| rm_work | typo | 18:29 |
| xgerman | I like objects | 18:29 |
| dougwig | much prefer B. | 18:29 |
| rm_work | fixed: http://pastebin.com/4TWEpUXY | 18:29 |
| rm_work | anywho yeah | 18:29 |
| rm_work | k | 18:29 |
| rm_work | I do too | 18:29 |
| rm_work | also, container_id vs. container_ref | 18:30 |
| rm_work | theoretically supporting container_ref is more flexible | 18:30 |
| rm_work | because it would support multiple barbican repos | 18:30 |
| rm_work | and be less config on our side | 18:30 |
| blogan | should line 21 be cert_info instead of tls_info? | 18:30 |
| rm_work | as long as the barbican repo supported the identity federation correctly | 18:30 |
| rm_work | blogan: yes, see my second paste :P | 18:30 |
| rm_work | that was the typo | 18:30 |
| rm_work | alright I am going to do that | 18:32 |
| rm_work | or as blogan points out, if we wanted something more like exhibit A, we could remove the class from the equation altogether and they'd be module methods | 18:33 |
| rm_work | since that's essentially already what they are | 18:33 |
| ptoohill | Yea, B is my preference | 18:33 |
| rm_work | but using the class would allow multiple subsequent "get()" calls to share a keystone auth | 18:33 |
| rm_work | if it's all for the same tenant | 18:33 |
| ptoohill | hmmm | 18:33 |
| rm_work | yeah, that's B | 18:34 |
| *** jorgem has joined #openstack-lbaas | 18:34 | |
| rm_work | *unless* we assume that the Trust is specific to a resource and not a user | 18:34 |
| rm_work | which COULD be the case in the far future | 18:34 |
| rm_work | then it can't share the keystone auth either way | 18:34 |
| rm_work | in that case it's really more like this anyway: | 18:37 |
| rm_work | http://pastebin.com/zz5cAHzr | 18:37 |
| rm_work | because trust_id is per-container, and consumer_url could feasibly be different if the object is cached/re-used? | 18:37 |
| rm_work | dunno if that's something we'd expect to happen ever tho | 18:38 |
| xgerman | now you lost me | 18:38 |
| rm_work | lol | 18:38 |
| rm_work | sometimes I ramble | 18:38 |
| rm_work | I operate very well with a sort of "stream of consciousness" dialogue going on :) | 18:38 |
| *** sbfox has joined #openstack-lbaas | 18:46 | |
| TrevorV | sbalukoff you runnin the meeting this afternoon again? | 18:48 |
| dougwig | rm_work: i think everyone said B, and at this point you are only arguing with yourself. :) | 19:00 |
| sbalukoff | TrevorV: Yep. | 19:01 |
| TrevorV | sweet sbalukoff, I'll be online for it :) | 19:03 |
| rm_work | well, I'm debating specifics | 19:06 |
| sbalukoff | rm_work: I'm also in favor of option B. :) | 19:07 |
| rm_work | yeah I am too | 19:08 |
| rm_work | just deciding exactly how to accomplish B | 19:08 |
| sbalukoff | Your most recent paste seems like a good way to do it, IMO. | 19:09 |
| sbalukoff | Since trust_id is per container. | 19:09 |
| sbalukoff | I wouldn't expect the consumer_url to change, but since it's a per-container attribute... again your most recent paste seems like a good way to go. | 19:10 |
| *** VijayB_ has quit IRC | 19:26 | |
| *** mwang2 has joined #openstack-lbaas | 19:57 | |
| *** jwarendt has joined #openstack-lbaas | 20:03 | |
| *** jwarendt has quit IRC | 20:03 | |
| *** dlundquist has joined #openstack-lbaas | 20:10 | |
| *** dlundquist has left #openstack-lbaas | 20:13 | |
| *** xgerman_ has joined #openstack-lbaas | 20:17 | |
| *** VijayB has joined #openstack-lbaas | 20:22 | |
| *** vivek-ebay has joined #openstack-lbaas | 20:23 | |
| *** sbfox has quit IRC | 20:26 | |
| rohara | sbalukoff: i'm travelling this week and might not be at the meeting today | 20:34 |
| sbalukoff | rohara: The meeting is underway right now. :) | 20:35 |
| sbalukoff | rohara: But that's OK, in any case. | 20:35 |
| *** sbfox has joined #openstack-lbaas | 20:37 | |
| rohara | sbalukoff: gah my timezone is off | 20:37 |
| sbalukoff | No worries. :) | 20:40 |
| blogan | hello | 20:59 |
| *** xgerman has quit IRC | 20:59 | |
| *** xgerman_ is now known as xgerman | 20:59 | |
| blogan | so handler (name can be changed, and probably should be) is just an easy way to swap out methods to get requests to the controller | 21:00 |
| sbalukoff | blogan: That sounds like a good idea to me. | 21:00 |
| xgerman | We can always use a queue; zeromq now and something better later? | 21:00 |
| sbalukoff | This should lead to more loosely coupled code, which is what we're going to need when we go to multiple controllers anyway, right? | 21:00 |
| johnsom_ | I am thinking zeromq as a start | 21:01 |
| blogan | sbalukoff: yes indeed | 21:01 |
| blogan | 0.5 was supposed to be just be straight to the controller | 21:01 |
| xgerman | well, zeromq is straight | 21:01 |
| sbalukoff | Yeah, but also with the intent to eventually move to v1.0 and v2.0 | 21:01 |
| sballe | if we do a use a queue we should use oslo.messaging since that will allow us to swap out the queue based on the OS. for example ubuntu uses mostly RabbitMQ. I am told feodora used qpid | 21:02 |
| sbalukoff | Better question: Is anyone objecting to this? | 21:02 |
| blogan | well then a zeromq handler can be created | 21:02 |
| TrevorV | I have one problem with its existence: I feel its unnecessary. Why wouldn't the API just send the request to the queue? blogan posed the "what if the operator doesn't want to use a queue? then toggling versions of the API is difficult" | 21:02 |
| johnsom_ | Yeah, later versions should use a real queue. Oslo messaging or something... | 21:02 |
| TrevorV | I was just wondering what the community thought about it all, hence the question | 21:02 |
| xgerman | we love queues! | 21:03 |
| blogan | yeah definitely, and the handler will make it much easier to swap out the real queue with say a zeromq solution | 21:03 |
| xgerman | I am questioning the need for a handler | 21:03 |
| TrevorV | xgerman same | 21:03 |
| sballe | me too | 21:03 |
| xgerman | oslo messaging is the abstraction layer we aim for :-) | 21:03 |
| sbalukoff | blogan: What would the handler get us that a queuing system won't? | 21:03 |
| johnsom_ | xgerman +1 | 21:04 |
| sballe | xgerman: +1 | 21:04 |
| blogan | well the main thing is we don't have to go changing code in the resource layer of the api, we'll just swap out a module for another | 21:04 |
| sbalukoff | How hard to you see it being, to have to change that code? | 21:04 |
| blogan | and i know some people at rackspace have wanted to be able to have a full test deployment without queues | 21:05 |
| blogan | so this would just give the ability to quickly swap in and out instead of changing the code itself | 21:05 |
| sbalukoff | Well, eventually queues are going to be part of the equation, I think, right? We can't really do this without them in v1.0. | 21:05 |
| sballe | sbalukoff: +1 | 21:06 |
| xgerman | +1 | 21:06 |
| TrevorV | sbalukoff I don't think we're talking about removing queue's in all of our ideal situations | 21:06 |
| TrevorV | Its the necessity of the Handler that we're talking about | 21:06 |
| johnsom_ | sbalukoff: +1 | 21:06 |
| TrevorV | Should the API communicate with the queue, or a handler | 21:06 |
| sbalukoff | TrevorV: Right. | 21:06 |
| xgerman | well, is oslo too hard to work with? | 21:06 |
| xgerman | I rather have queues sooner than later :-) | 21:07 |
| sballe | I agree we should go API --> oslo messaging -> queue | 21:07 |
| sbalukoff | My point is that wanting to test without using a queue in v1.0 and beyond probably doesn't make a lot of sense, since any production deployment will definitely use queues. | 21:07 |
| sbalukoff | I gues.. | 21:07 |
| blogan | very well, i was just thinking a more abstracted approach might be better so that we don't have to change the code much | 21:08 |
| TrevorV | sbalukoff it depends on what you're testing, right? | 21:08 |
| sbalukoff | Well, removing the queue for testing purposes does eliminate that as a potential source of failure if you're not actually interested in testing the queue... | 21:08 |
| TrevorV | I'm not fully against the handler, since, as blogan points out, the abstraction could be nice depending on the situation. I was looking for a reason to keep it that way or to go straight from API | 21:08 |
| blogan | i just didn't want all the queue setup code in the API layer, it would be in this other layer, just seemed cleaner | 21:08 |
| sbalukoff | blogan: How strongly do you feel that way? | 21:09 |
| TrevorV | sbalukoff strong enough that he beat me up when I opposed :( | 21:09 |
| TrevorV | nah I'm kidding | 21:10 |
| sbalukoff | TrevorV: Haha! | 21:10 |
| blogan | stronger than most, but i won't rage | 21:10 |
| * TrevorV rubs his bruises | 21:10 | |
| rohara | i feel like the Tacker (ServiceVM) project tackled a similar problem | 21:10 |
| blogan | rohara could you expound on this | 21:10 |
| sbalukoff | blogan: If you think the code will be significantly cleaner (and therefore easier to test, debug and maintain), that is potentially a good reason to have a handler. | 21:10 |
| sbalukoff | I really don't have a strong opinion either way on this-- I'm mostly still trying to understand all the pros and cons of either approach. | 21:11 |
| rohara | blogan: i cam trying to remember the details. i admit i have not followed tacker as closely as i had wanted | 21:11 |
| johnsom_ | blogan: In a deployment, where would this handler live? | 21:12 |
| blogan | well are there any really strong objections? | 21:12 |
| TrevorV | blogan mostly from me it seems ha ha | 21:12 |
| TrevorV | Which I'm okay with it for its modularity | 21:12 |
| sballe | blogan: I am not sure what it give us. | 21:12 |
| blogan | johnsom_: its just a code piece, not another component, the API code would pass it to the handler, then the handler would do whatever it needs to do to get the data to the controller | 21:13 |
| johnsom_ | Ok | 21:13 |
| TrevorV | sballe simplification of API layer, modular location for queue interfacing code | 21:13 |
| sballe | and I am worried taht we won;t see a lot of the issues we will be runninginto when we switch to a queue | 21:13 |
| xgerman | oslo dies remote RPC so basically your handler would be call ('x') on the server | 21:13 |
| blogan | sballe: a cleaner abstraction layer, separation of code, easier to test | 21:13 |
| TrevorV | sballe this isn't a queue replacement, its just a layer between API and Queue | 21:14 |
| rohara | blogan: i am thinking of the rpc proxy blueprint | 21:14 |
| rohara | https://blueprints.launchpad.net/oslo.messaging/+spec/message-proxy-server | 21:14 |
| sbalukoff | sballe: Yep, we're still talking about having queues in v1.0 at least (and possibly v0.5?) | 21:14 |
| rohara | probably not a good comparison | 21:14 |
| sballe | so it would be API --> handler --> oslo.messaging -> queue | 21:14 |
| blogan | sballe: yes or API --> handler --> controller if one wanted | 21:15 |
| johnsom_ | sbalukoff: Frankly I would like to see the oslo messaging in 0.5. | 21:15 |
| blogan | or API --> handler --> oslo.messagingv2 --> queue | 21:15 |
| sbalukoff | sballe: The handler is just a portion of the code. It would effectively be part of the API stuff, but keeps queue communications cleanly outside of other API concerns. | 21:15 |
| TrevorV | sballe in the case that one doesn't want to use a queue (for any given reason... ex: faster testing) | 21:15 |
| sbalukoff | Unless I'm misunderstanding something entirely... | 21:16 |
| xgerman | https://wiki.openstack.org/wiki/Oslo/Messaging#Client_Side_API | 21:16 |
| sbalukoff | (Which is totally possible. I'm somewhat of an idiot, after all.) | 21:16 |
| blogan | sbalukoff: that is correct | 21:17 |
| xgerman | a call to the queu is a 3 line affair | 21:17 |
| xgerman | so in my opinion that doesn't need a driver but... | 21:17 |
| * TrevorV kicks xgerman under the table for saying 'driver' in this case | 21:17 | |
| sbalukoff | xgerman: I don't think this is a "driver" per se. But you're right that just using Oslo here might be the abstraction that satisfies blogan's concern? | 21:18 |
| sbalukoff | blogan? | 21:18 |
| sballe | sbalukoff: +1 | 21:18 |
| blogan | well it doesn't provide the abstraction if i dont want a queue at all | 21:18 |
| rm_work | yeah I wouldn't bother with a handler layer | 21:19 |
| blogan | but if we're changing the scope of 0.5 to now have a queue, then this would have never come up | 21:19 |
| TrevorV | blogan that's fair | 21:19 |
| rm_work | oslo.queue(thing) if queue else do(thing) | 21:19 |
| sbalukoff | blogan: True... are you thinking something that is just a really light-weight wrapper around Oslo calls then? Something that can short-circuit and avoid the queue if the queue isn't desired for certain testing scenarios? | 21:19 |
| sbalukoff | Again, we're not going to be able to avoid having a queue in v1.0 and beyond. | 21:19 |
| sballe | sbalukoff: +1 | 21:20 |
| sbalukoff | So the idea of testing without a queue really starts to be less meaningful with v1.0 and beyond. | 21:20 |
| blogan | oh i bet we coudl, but i wouldn't go for it | 21:20 |
| rm_work | oslo.queue(thing) if queue else do(thing) | 21:20 |
| rm_work | oslo.queue(thing) if queue else do(thing) | 21:20 |
| rm_work | ^^ | 21:20 |
| blogan | yes we saw it | 21:20 |
| rm_work | well, you didn't seem to be appropriately in awe of the simplicity | 21:20 |
| TrevorV | Should we call a vote? For/Against? | 21:21 |
| blogan | no i think im the only one | 21:21 |
| sbalukoff | blogan: It is true that introducing a queue in v0.5 would be a significant change of scope. | 21:21 |
| rm_work | note that this is also what Barbican does right now | 21:21 |
| rm_work | oooo votes! | 21:21 |
| blogan | but we need to update 0.5 to now have a queue | 21:21 |
| rm_work | also it would make less temp-work | 21:21 |
| xgerman | I am ok with that | 21:21 |
| rohara | i'm willing to vote on if we vote | 21:21 |
| xgerman | having queu in .5 | 21:21 |
| TrevorV | Wait, so did the discussion change to "we want a queue in 0.5" now? | 21:22 |
| johnsom_ | Agreed, it is a change in scope, but I think it is the right plan. In my controller thinking I have had a queue penciled in... | 21:22 |
| TrevorV | We apparently agree on "no handler" | 21:22 |
| sballe | Can we still get an Octavia+Neutron LBaaS 0.5 in kilo if we add a queue? | 21:22 |
| sballe | sorry Octavia 0.5 _ Neutron LBaaS V2 | 21:23 |
| sbalukoff | Hmmmm.... | 21:23 |
| dougwig | forgive the stupid question, but if we're using an IPC queue, what is the point of fronting it with HTTP? we can just have the lbaas driver do a queue insertion. | 21:24 |
| rm_work | I think so? it's not a HUGE change | 21:24 |
| rm_work | and does prevent some future rewrites and some possible complexity from dealing with two ways of doing things | 21:24 |
| rm_work | sballe: ^^ | 21:24 |
| xgerman | +1 | 21:24 |
| sbalukoff | dougwig: We'll still need an Operator API. | 21:24 |
| blogan | dougwig: i believe that was the original plan, but since we weren't having a queue we needed a way to actually send creates to the controller | 21:24 |
| xgerman | +1 | 21:24 |
| sbalukoff | And Neutron LBaaS v2 does not handle operator API stuff. | 21:24 |
| xgerman | yep | 21:25 |
| blogan | this was a discussion on the operator-api spec | 21:25 |
| dougwig | aren't there about a metric bajillion web apps out there that have solved this problem without needing rabbit? seems like we should just do http OR a queue. both some weird mix of both. | 21:25 |
| sballe | sbalukoff: I agree. I just put the Operator API under Octavia. | 21:25 |
| dougwig | /both some/not some/ | 21:25 |
| blogan | oh oh, one more reason i wanted the handler, which was a cherry on the top, is because it would eseentially become the same thing as the neutron lbaas driver layer if the octavia API ever became the openstack lbaas | 21:25 |
| blogan | but i don't know if that is that important | 21:25 |
| sbalukoff | sballe: +1 | 21:25 |
| sbalukoff | blogan: Ok, again, I'm not hearing any strong revulsion to the idea of a light-weight handler which (in v1.0) will wrap queue commands. | 21:27 |
| TrevorV | sbalukoff I'm thinking there needs to be an executive decision here then, yay or nay? | 21:28 |
| rm_work | sbalukoff: I'm also not hearing any strong opinions FOR it | 21:28 |
| sbalukoff | So... I'm not in principle against the idea, and I'm definitely for code which is more modular, and simpler to test, debug, and maintain. | 21:28 |
| rm_work | (other than blogan) | 21:28 |
| TrevorV | sbalukoff said "yes handler" you read it here folks, we doin a handler | 21:29 |
| sbalukoff | Ok, then executive decision is this: blogan wants to write it, there's are some good reasons to have it, not strong reasons not to have it... so, go for it! | 21:29 |
| blogan | hoenstly the main reason was support no queue and queue | 21:29 |
| sballe | I guess we can always take it out later if it doesn't make sense to have it. | 21:30 |
| sbalukoff | sballe: If it's lightweight, that shouldn't be hard. | 21:30 |
| TrevorV | Alright, so we're decided to keep it as it is described. | 21:30 |
| TrevorV | Sweet, discussion moot :P | 21:31 |
| sbalukoff | TrevorV: I don't think this was a worthless discussion. | 21:31 |
| sballe | I still thinking about the no queue and queue options and I am not totally convinced that that is a good reason at least not for HP. But if RAX has that need then we should make sure they get waht thye need too | 21:31 |
| * TrevorV was joking and sbalukoff didn't know..... | 21:31 | |
| sbalukoff | TrevorV: I'm immune to sarcasm. | 21:31 |
| xgerman | sballe +1 | 21:32 |
| TrevorV | Alright, I'm off, talk to you guys in the morning for neutron lbaas (potentially :D ) | 21:32 |
| sbalukoff | xgerman and sballe: Yeah, I agree-- I don't see testing without a queue being all that relevant for us either-- but blogan did seem to think this would make the code cleaner and simpler to maintain, test, and troubleshoot. And I'm definitely in favor of that. | 21:34 |
| sbalukoff | I'm inclined to believe he's right in that prediction. | 21:35 |
| rm_work | ugh, I will type at you in the morning, but I give no guarantees about whether I'll really *be there* | 21:36 |
| rm_work | no clue how sbalukoff manages, in PDT | 21:36 |
| sbalukoff | rm_work: I have a confession to make: I actually fell asleep again 15 minutes into last week's meeting. XD | 21:37 |
| sbalukoff | I'm just glad I wasn't stuck with my face on the x key or something. | 21:37 |
| rm_work | heh | 21:37 |
| rm_work | I ... have also fallen asleep in the middle of one of those meetings before T_T | 21:37 |
| sbalukoff | It's about to get even suckier as the daylight savings time shift happens... | 21:40 |
| sbalukoff | The 6:00-7:00am hour is the Evil hour: If you're awake then you've either stayed up too late, or gotten up to early. | 21:40 |
| sballe | Wow 6am :-( | 21:41 |
| sbalukoff | (Keep in mind that my usual bed time is about 3:00am... I'm very much a night owl.) | 21:42 |
| rm_work | sbalukoff: same | 21:56 |
| rm_work | 6-7am is ungodly | 21:57 |
| rm_work | i am really tempted to write a bot that says my status update when you do like... #rm_update | 21:57 |
| sballe | rm_work: You are Central Timezone so it is not that bad ;) | 21:57 |
| rm_work | sballe: still pretty bad T_T | 21:57 |
| sballe | 8am? | 21:57 |
| rm_work | especially when jorgem makes me be *at work* for the meeting | 21:57 |
| sbalukoff | Heh! | 21:58 |
| * rm_work glares menacingly at jorgem | 21:58 | |
| * sballe lol | 21:58 | |
| *** dboik has quit IRC | 22:00 | |
| *** mwang2 has quit IRC | 22:05 | |
| *** vivek-ebay has quit IRC | 22:08 | |
| *** jorgem has quit IRC | 22:40 | |
| *** vivek-ebay has joined #openstack-lbaas | 22:59 | |
| *** ptoohill-oo has joined #openstack-lbaas | 23:11 | |
| *** mlavalle has quit IRC | 23:18 | |
| *** ptoohill-oo has quit IRC | 23:28 | |
| *** ptoohill-oo has joined #openstack-lbaas | 23:30 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!
