| *** crc32 has quit IRC | 00:01 | |
| *** vivek-ebay has quit IRC | 00:06 | |
| dougwig | vjay: there's an ML thread about the agenda for tomorrow. please reply to that with the things you want to discuss. | 00:07 |
|---|---|---|
| *** xgerman has quit IRC | 00:23 | |
| *** dlundquist has left #openstack-lbaas | 00:26 | |
| openstackgerrit | Stephen Balukoff proposed a change to stackforge/octavia: Octavia Component Design v1.0 from ML discussion https://review.openstack.org/111440 | 00:41 |
| *** sbfox1 has quit IRC | 00:46 | |
| *** vjay2 has joined #openstack-lbaas | 00:46 | |
| *** vjay has quit IRC | 00:46 | |
| *** fnaval has quit IRC | 00:47 | |
| *** fnaval has joined #openstack-lbaas | 00:48 | |
| *** fnaval has quit IRC | 00:53 | |
| *** sbfox has joined #openstack-lbaas | 00:56 | |
| *** vjay2 has quit IRC | 01:34 | |
| *** vivek-ebay has joined #openstack-lbaas | 01:51 | |
| *** vjay has joined #openstack-lbaas | 02:14 | |
| blogan | hello | 02:16 |
| blogan | vjay you around? | 02:16 |
| *** vivek-ebay has quit IRC | 02:25 | |
| *** vjay2 has joined #openstack-lbaas | 02:31 | |
| *** vjay has quit IRC | 02:31 | |
| *** vjay2 has quit IRC | 02:31 | |
| *** vjay has joined #openstack-lbaas | 02:31 | |
| *** vjay2 has joined #openstack-lbaas | 02:32 | |
| *** vjay has quit IRC | 02:32 | |
| *** VijayB_ has quit IRC | 02:35 | |
| *** vjay2 has quit IRC | 02:37 | |
| *** fnaval has joined #openstack-lbaas | 02:41 | |
| *** vivek-ebay has joined #openstack-lbaas | 02:43 | |
| *** woodster has quit IRC | 02:45 | |
| *** vivek-ebay has quit IRC | 03:04 | |
| *** fnaval has quit IRC | 03:09 | |
| *** woodster_ has joined #openstack-lbaas | 03:30 | |
| *** fnaval has joined #openstack-lbaas | 03:30 | |
| *** HenryG is now known as HenryG_afk | 03:31 | |
| *** sbfox has quit IRC | 04:45 | |
| *** fnaval has quit IRC | 04:54 | |
| *** fnaval has joined #openstack-lbaas | 04:55 | |
| *** fnaval has quit IRC | 05:00 | |
| *** amotoki_ has joined #openstack-lbaas | 05:43 | |
| *** amotoki_ has quit IRC | 06:05 | |
| *** amotoki has joined #openstack-lbaas | 06:05 | |
| *** evgenyf has joined #openstack-lbaas | 07:21 | |
| *** [1]evgenyf has joined #openstack-lbaas | 07:37 | |
| *** evgenyf has quit IRC | 07:40 | |
| *** [1]evgenyf is now known as evgenyf | 07:40 | |
| *** enikanorov__ has quit IRC | 08:58 | |
| *** enikanorov has joined #openstack-lbaas | 08:58 | |
| *** amotoki has quit IRC | 09:16 | |
| *** evgenyf has quit IRC | 09:34 | |
| *** evgenyf has joined #openstack-lbaas | 09:38 | |
| *** HenryG_afk is now known as HenryG | 12:18 | |
| *** fnaval has joined #openstack-lbaas | 13:03 | |
| *** fnaval has quit IRC | 13:44 | |
| *** fnaval has joined #openstack-lbaas | 13:44 | |
| *** fnaval has quit IRC | 13:49 | |
| *** vjay has joined #openstack-lbaas | 13:52 | |
| *** jorgem has joined #openstack-lbaas | 13:55 | |
| *** jorgem has quit IRC | 13:55 | |
| *** jorgem has joined #openstack-lbaas | 13:55 | |
| *** xgerman has joined #openstack-lbaas | 13:59 | |
| *** rolledback has joined #openstack-lbaas | 14:12 | |
| *** fnaval has joined #openstack-lbaas | 14:13 | |
| *** samuelbercovici has joined #openstack-lbaas | 14:16 | |
| *** rolledback has quit IRC | 14:16 | |
| *** rolledback has joined #openstack-lbaas | 14:17 | |
| *** tmc3inphilly has joined #openstack-lbaas | 14:18 | |
| *** vivek-ebay has joined #openstack-lbaas | 14:19 | |
| *** vivek-ebay has quit IRC | 14:22 | |
| *** crc32 has joined #openstack-lbaas | 14:33 | |
| *** vivek-ebay has joined #openstack-lbaas | 14:36 | |
| *** markmcclain has joined #openstack-lbaas | 14:45 | |
| *** markmcclain has quit IRC | 14:49 | |
| *** markmcclain has joined #openstack-lbaas | 14:49 | |
| *** vivek-ebay has quit IRC | 14:52 | |
| *** jorgem has quit IRC | 14:58 | |
| *** samuelbercovici has quit IRC | 14:59 | |
| *** vjay has quit IRC | 15:00 | |
| *** jorgem has joined #openstack-lbaas | 15:01 | |
| *** tmc3inphilly has quit IRC | 15:01 | |
| *** jorgem has quit IRC | 15:01 | |
| *** jorgem has joined #openstack-lbaas | 15:01 | |
| *** jorgem has quit IRC | 15:01 | |
| *** rolledback has quit IRC | 15:03 | |
| *** vivek-ebay has joined #openstack-lbaas | 15:18 | |
| *** fnaval has quit IRC | 15:19 | |
| *** fnaval has joined #openstack-lbaas | 15:20 | |
| *** fnaval has quit IRC | 15:24 | |
| *** sbfox has joined #openstack-lbaas | 15:28 | |
| *** vjay has joined #openstack-lbaas | 16:02 | |
| *** sbfox1 has joined #openstack-lbaas | 16:05 | |
| *** sbfox has quit IRC | 16:06 | |
| *** Youcef has joined #openstack-lbaas | 16:13 | |
| *** vivek-ebay has quit IRC | 16:17 | |
| *** evgenyf has quit IRC | 16:17 | |
| dougwig | morning all | 16:17 |
| dougwig | rm_work: what did you end up doing in the barbican review to fix the test? i don't see any more sleeps | 16:18 |
| *** vivek-ebay has joined #openstack-lbaas | 16:35 | |
| *** vivek-ebay has quit IRC | 16:39 | |
| *** vivek-ebay has joined #openstack-lbaas | 16:40 | |
| *** vivek-eb_ has joined #openstack-lbaas | 16:41 | |
| *** vivek-ebay has quit IRC | 16:41 | |
| *** sbfox1 has quit IRC | 16:48 | |
| *** rolledback has joined #openstack-lbaas | 17:02 | |
| *** rolledback has quit IRC | 17:07 | |
| *** markmcclain has quit IRC | 17:08 | |
| *** sbfox has joined #openstack-lbaas | 17:21 | |
| *** VijayB_ has joined #openstack-lbaas | 17:30 | |
| *** vivek-eb_ has quit IRC | 17:35 | |
| *** vivek-ebay has joined #openstack-lbaas | 17:35 | |
| *** vjay has quit IRC | 17:38 | |
| *** vjay has joined #openstack-lbaas | 17:38 | |
| *** vivek-ebay has quit IRC | 17:54 | |
| *** vivek-ebay has joined #openstack-lbaas | 17:54 | |
| *** vivek-ebay has quit IRC | 18:01 | |
| *** vivek-ebay has joined #openstack-lbaas | 18:01 | |
| *** sballe has joined #openstack-lbaas | 18:02 | |
| *** sballe has quit IRC | 18:02 | |
| *** sbalukoff has quit IRC | 18:17 | |
| *** markmcclain has joined #openstack-lbaas | 18:33 | |
| *** VijayB_ has quit IRC | 18:34 | |
| *** markmcclain1 has joined #openstack-lbaas | 18:37 | |
| *** markmcclain has quit IRC | 18:39 | |
| *** mlavalle has joined #openstack-lbaas | 18:54 | |
| *** markmcclain1 has quit IRC | 18:56 | |
| *** VijayB_ has joined #openstack-lbaas | 18:57 | |
| *** markmcclain has joined #openstack-lbaas | 18:58 | |
| dougwig | is it really this quiet today, or did the server split? | 19:03 |
| blogan | just got back from meetings and team lunch | 19:06 |
| *** rolledback has joined #openstack-lbaas | 19:13 | |
| *** sbfox has quit IRC | 19:13 | |
| *** sbalukoff has joined #openstack-lbaas | 19:22 | |
| rm_work | dougwig: see the change it is rebased onto as a dependency | 19:26 |
| rm_work | dougwig: I fixed the problem (not a problem with my code -- a problem with the barbican API as a whole) | 19:26 |
| rm_work | but it is a different CR because it's unrelated to what I was doing | 19:26 |
| dougwig | ahh, sweet. | 19:28 |
| *** sbfox has joined #openstack-lbaas | 19:43 | |
| TrevorV | sbalukoff, should I still expect the 0.5 docs to drop early next week? | 19:57 |
| *** VijayB_ has quit IRC | 19:57 | |
| *** vivek-ebay has quit IRC | 20:07 | |
| *** vivek-ebay has joined #openstack-lbaas | 20:07 | |
| sbalukoff | TrevorV: Yes. | 20:08 |
| *** VijayB_ has joined #openstack-lbaas | 20:08 | |
| sbalukoff | I'll try to get them out by EOD Friday, but I don't want to make a promise about that because I know what my schedule looks like between now and then. ;) | 20:08 |
| sbalukoff | Man, this GBP thread is looooooong. | 20:08 |
| sbalukoff | And yes, I totally understand what irony is. | 20:12 |
| dougwig | the gbp thread is also nothing new (and i've only been working with neutron for 4 months.) same root issue: project has conflicting goals/velocities and insufficient review bandwidth. so let's have a 1000 email thread with an end result of, "no, no, keep it in neutron. maybe it'll get better." | 20:14 |
| *** rolledback has quit IRC | 20:15 | |
| dougwig | i think that we, as a team, should come up with what kinds of alternate structure we could live with, while we can still influence what that might look like. because the gbp problem is our problem too, as blogan said in the meeting, and that thread is not generating any ideas. i'm glad that mestery is considering alternatives. | 20:16 |
| blogan | i think we need better defined requirements for how an "experimental" feature gets merged into neutron, will neutron cores have to review the entire feature codebase just to make sure it doesn't mess anything up (which is the same problem we have now) | 20:18 |
| blogan | also, if it is outside the neutron tree does that mean it only interacts with neutron through the neutron API, or it just something that imports the neutron modules and uses those. | 20:19 |
| dougwig | i'm actually fine with importing neutron in the near-term. the definition of neutron today is so broad that it almost has to split or go hierarchical. | 20:24 |
| blogan | im fine with it too, but i know others probably want it in Juno, which means in an openstack project, and i don't want to ignore their needs | 20:25 |
| dougwig | what has always puzzled me is why it can't be both part of neutron and not. i mean, you have to install more than one package to install most any openstack project, and this could be similar. add this package to lbaas, this for vpn, ... it doesn't necessarily mean that it has to be a whole separate stackforge thing. | 20:26 |
| *** fnaval has joined #openstack-lbaas | 20:33 | |
| blogan | because of the marketing, if an operator advertises that they are purely openstack then they kind of have to abide by that as much as they can | 20:35 |
| *** markmcclain has quit IRC | 20:35 | |
| dougwig | i'm beginning unclear. you have "nova-api" and "nova-compute" now. you could have "neutron" and "neutron-lbaas" and "neutron-vpn", all of which are openstack, but the package separation provides an opportunity to do process/review separations as needed as well. | 20:36 |
| dougwig | /beginning/being/ | 20:36 |
| dougwig | it's a hybrid of totally spun out and keeping it all in neutron. | 20:36 |
| blogan | ah yeah i see | 20:37 |
| blogan | sounds like what the networking program will be aiming for | 20:37 |
| dougwig | alright, i will have two dozen kids at my house shortly for my daughters' birthday party, and now i have to drive home to chaperone. wish me luck/sanity. | 20:38 |
| blogan | good luck sir | 20:55 |
| *** VijayB_ has quit IRC | 20:57 | |
| sbalukoff | Heh! Good luck! | 21:00 |
| sbalukoff | I think there's a lot of paranoia around whether a change to the core ends up breaking things on the periphery (like LBaaS, FWaaS, GBP, etc.) | 21:01 |
| sbalukoff | Hence the reason people want these things to be part of Neutron proper: | 21:01 |
| sbalukoff | So that once it's in, it's the burden of whoever is proposing the change to make sure they don't break these periphery items in the process. | 21:01 |
| sbalukoff | Also, the fact that things need to be so tightly coupled with Neutron presently (ie. importing neutron modules) is an indicator that it doesn't have a very mature API. | 21:03 |
| sbalukoff | Which, I guess, is not that surprising given OpenStack in general has only been around since 2010. | 21:03 |
| sbalukoff | And networking touches everything. | 21:03 |
| blogan | yeah but if the wish is for nova to consume neutron to meet their needs, then it shouldn't be far fetched for that same requirement to be met for lbaas | 21:04 |
| sbalukoff | Sure. | 21:04 |
| sbalukoff | Mostly, I'm just blabbering about "how we got here" and I'm definitely not saying "this is how it should be." | 21:05 |
| sbalukoff | I heard a nasty rumor that GBP was being pushed by a specific vendor in order to get a foothold they could uniquely use to capture more of the OpenStack market. If true, it's pretty unethical and should be stopped, IMO. But, I know next to nothing about GBP, so I'm trying to ascertain the truth of the rumor. | 21:06 |
| sbalukoff | And it's just pisses me off if controversy over that ends up causing problems for LBaaS code acceptance. | 21:07 |
| dougwig | sbalukoff: the coupling issue could be dealt with via ci that tests the umbrella as a whole, being a gate all the way up the chain. | 21:07 |
| blogan | i haven't heard that rumor, and honestly from what I can tell about GBP is that it is really just an abstraction for things that can be accomplished already through security groups and fwaas | 21:07 |
| sbalukoff | dougwig: I agree. | 21:08 |
| sbalukoff | blogan: Yep. But it being a "power play" on somebody's part makes sense: | 21:08 |
| dougwig | this isn't coming to a head because of Gbp. that's just a symptom, IMO. | 21:08 |
| sbalukoff | 1. First you get the functionality into OpenStack so you can claim to be the only vendor that supports the functionality in some high-performance way. | 21:09 |
| *** VijayB has joined #openstack-lbaas | 21:09 | |
| sbalukoff | 2. Then you push people to use the new API-- once you have a significant customer base, the feature isn't going to go away easily. | 21:09 |
| sbalukoff | 3. Make sure you have software patents in place preventing other vendors from developing key features which enable the high performance functionality you're selling. | 21:10 |
| sbalukoff | Pretty sneaky, if true. | 21:10 |
| dougwig | Wouldn't that violate the open source reference requirement? | 21:12 |
| *** fnaval has quit IRC | 21:12 | |
| sbalukoff | open source reference has to be functional, not high performance. | 21:12 |
| *** fnaval has joined #openstack-lbaas | 21:13 | |
| blogan | well its all speculation at this point | 21:13 |
| sbalukoff | But reading through this thread, I'm mostly in the same boat as Aaron, not understanding the benefits this extra layer of abstraction buys. | 21:14 |
| dougwig | Eh, I don't see anyone mad that everyone using nova uses Intel CPUs. There's some over paranoia there, IMO. | 21:14 |
| sbalukoff | dougwig: Show me a competitive open-source chip manufacturer. ;) | 21:15 |
| dougwig | just as true with storage. and some networking. and secure stores. and... middle ground, and all that. | 21:16 |
| sbalukoff | Sure. I just think the OpenStack community is better off if more vendors can play. | 21:18 |
| rm_work | I was about to link to one, but then i realized you qualified it with "competetive" :P | 21:18 |
| dougwig | if you step back far enough, openstack is all glue. some parts are unquestionably vendor specific (CPUs, e.g.) some are almost religiously opposed. it's a weird dichotomy, is all. | 21:19 |
| sbalukoff | Indeed! | 21:19 |
| dougwig | sbalukoff: 1000% agreed. | 21:19 |
| dougwig | it's an interesting sign of when something starts becoming commodity, when a fast open source alternative exists. on the flip side, if you focus on that too much, you lock out a bunch of non-commodity interesting stuff. i've pondered this for awhile, and if you think about it with openstack, the reason it seems to work is that everywhere that hardware is | 21:21 |
| dougwig | basically required, it's not openstack proper abstracting to it, but rather some intermediate open-source library that wasn't quite so dogmatic (libvirt, iscsi, etc.) | 21:21 |
| dougwig | it's likely useful armor for openstack to have right now, since it's so popular that the vendor attacks will come fast and furious for awhile. | 21:23 |
| sbalukoff | Heh! Indeed. | 21:24 |
| sbalukoff | I guess what I'm trying to ascertain is "is GPB a vendor attack?" | 21:24 |
| sbalukoff | Er.. GBP | 21:24 |
| sbalukoff | And at the same time, "Why the hell should anything going on in GBP delay merging of LBaaS-related patches?" | 21:25 |
| sbalukoff | Or, "Why do we have to go sit in the timeout corner as well when we didn't do anything wrong?" ;) | 21:25 |
| rm_work | £ is a vendor attack? | 21:25 |
| dougwig | btw, the beneficial use case is for users that aren't networking experts. have your network guru setup a policy for vxlan secure wan access to replicated databases, and then the guy building the application just says, "gimme two instances, and connect 'em like db's across a wan". | 21:25 |
| dougwig | sbalukoff: because it ain't a gbp problem. it's a review bandwidth/conflicting goal problem of the project at large. | 21:26 |
| dougwig | another way to think about the feature is that it's like juju charms, hidden behind the neutron api. likely has a lot of overlap with heat. | 21:32 |
| *** markmcclain has joined #openstack-lbaas | 21:34 | |
| *** vjay has quit IRC | 21:35 | |
| *** vjay has joined #openstack-lbaas | 21:36 | |
| *** vjay has quit IRC | 21:43 | |
| *** rohara has quit IRC | 21:54 | |
| *** jorgem has joined #openstack-lbaas | 21:58 | |
| xgerman | I missed the big gbp discussion here and I prepared by resing e-mails for 40 minutes this morning | 22:00 |
| xgerman | and now i know more about the semantic of endpoints then I ever wanted to know :-( | 22:00 |
| *** sbfox has quit IRC | 22:10 | |
| *** sbfox1 has joined #openstack-lbaas | 22:10 | |
| dougwig | hmm, piñata duty is imminent. i might not be able to hide through that. | 22:11 |
| sbalukoff | Haha | 22:11 |
| sbalukoff | I'm a slow reader... about half-way through that discussion now. | 22:11 |
| sbalukoff | I think I understand what GBP is now, but I also think that the proposal Mark made about keeping alternate APIs in stackforge until it's proved doesn't apply to us for a couple reasons. | 22:12 |
| sbalukoff | This is because: The stuff we're doing in Neutron LBaaS actually is exposing new functionality (or laying the groundwork to do so for features like TLS and L7). | 22:12 |
| sbalukoff | And 2: We're actually already doing that with Octavia. The long-term goal of Octavia is to become the new reference implementation for satisfying the user API for LBaaS in OpenStack. Of course we don't expect it to be merged into the OpenStack canon until it's ready. :/ | 22:14 |
| sbalukoff | It sounds like the GBP folks really, *really* are dissatisfied with the idea that their stuff should remain in stackforge until it's proved. | 22:14 |
| sbalukoff | The people who are for doing this seem to mostly be Neutron core devs, and they seem to have pretty sound reasoning in the thread. | 22:14 |
| dougwig | I think the counter argument would be that lbaas is not switches and ports, so it is just a higher level API. | 22:15 |
| rm_work | I still haven't even looked at the £ thread… should I really? >_> | 22:15 |
| sbalukoff | It turns out that GBP is just manipulating Neutron primitives anyway. | 22:15 |
| sbalukoff | So, it's not really switches and ports in and of itself either. | 22:15 |
| sbalukoff | It's more like an orchestration layer. | 22:15 |
| dougwig | rm_work: tldr - there aren't enough reviewers | 22:15 |
| rm_work | yeah, we knew that <_< | 22:15 |
| sbalukoff | It's not just that there aren't enough reviewers. | 22:16 |
| rm_work | awesome. | 22:16 |
| sbalukoff | It's also that there's not a good way for sweeping changes to make it into Neutron. | 22:16 |
| sbalukoff | Which is something we've definitely encountered. | 22:16 |
| dougwig | A better counter argument. If it ain't in nova network, it should be outside neutron. Saying gbp should and lbaas shouldn't is an arbitrary distinction. | 22:17 |
| sbalukoff | So far, I've not seen anything in the thread which negates that rumor that GBP is effectively a power-play on the part of one particular vendor. :/ But I'm still reading. | 22:17 |
| dougwig | Might be that neutron core means different things to different people as well | 22:18 |
| sbalukoff | dougwig: Pish-posh! We always agree to the meaning of terms. | 22:18 |
| *** vivek-ebay has quit IRC | 22:22 | |
| *** vivek-ebay has joined #openstack-lbaas | 22:29 | |
| blogan | sbalukoff: i think this GBP discussion does apply to neutron lbaas v2 | 22:56 |
| blogan | sbalukoff: i mean mark's suggestion | 22:56 |
| *** xgerman has quit IRC | 22:56 | |
| *** markmcclain has quit IRC | 22:56 | |
| rm_work | why does no one else think it's hilarious that the acronym is GBP = £ | 23:11 |
| *** sbfox1 has quit IRC | 23:11 | |
| *** sbfox has joined #openstack-lbaas | 23:11 | |
| rm_work | T_T | 23:11 |
| blogan | rm_work: i got your first reference, i was just seeing how long it would take you until you outright said it because no one was acknowledging it | 23:12 |
| blogan | experiment has ended | 23:12 |
| dougwig | lol. i got it as well. | 23:12 |
| blogan | lol see | 23:12 |
| *** vivek-ebay has quit IRC | 23:12 | |
| rm_work | i knew you GOT it | 23:12 |
| rm_work | because you responded accordingly | 23:12 |
| rm_work | but no one cares as much as I do apparently :P | 23:13 |
| dougwig | i internally chuckled, if it helps. | 23:14 |
| *** vivek-ebay has joined #openstack-lbaas | 23:14 | |
| dougwig | can someone refresh my memory. why are we prefixing some foreign keys with "default_"? | 23:16 |
| *** vivek-ebay has quit IRC | 23:16 | |
| *** vivek-ebay has joined #openstack-lbaas | 23:19 | |
| *** sbfox has quit IRC | 23:25 | |
| *** sbfox has joined #openstack-lbaas | 23:25 | |
| *** sbfox has quit IRC | 23:27 | |
| blogan | dougwig: i was asking myself that before, i think it was because of having multiple pools in the future, seems like pool_id would be fine on the listener now | 23:27 |
| *** vivek-ebay has quit IRC | 23:27 | |
| dougwig | i remember that one. i was specifically looking at the tis review. | 23:28 |
| *** vivek-ebay has joined #openstack-lbaas | 23:28 | |
| blogan | if it is decided to change it then I think it shoudl be done quickly and in these first few patchsets before its engrained in the code and docs and cli | 23:29 |
| blogan | then again we may end up being an incubated api | 23:29 |
| *** VijayB has quit IRC | 23:30 | |
| sbalukoff | blogan: I'm prepared to argue that the Neutron LBaaS v2 API was also agreed upon a while ago, and that many key players presently working on Neutorn LBaaS had actually proposed building our own project, splitting away from Neutron... but that we thought Neutron core leadership was against this... hence the reason Octavia is a driver fro Neutron LBaaS instead of a stand-alone project. | 23:32 |
| sbalukoff | But... | 23:32 |
| *** jorgem has quit IRC | 23:32 | |
| blogan | sbalukoff: and I think this incubator will give a more defined path for spinning out | 23:32 |
| sbalukoff | Yep! | 23:32 |
| sbalukoff | In fact, I would say that what we're doing with Octavia actually follows the model that Mark proposed. | 23:33 |
| blogan | so I'm looking at it optimistically from both sides | 23:33 |
| blogan | yes, but he's specifically talking about neutron extensions I believe | 23:33 |
| sbalukoff | The code changes to Neutron LBaaS were because they didn't want us to abandon it, and because we needed Neutron LBaaS to support better model and better API in order to deliver what we want to with Octavia. | 23:33 |
| sbalukoff | But... our designs have been made to be loosely coupled with networking in any case. If we needed to spin it out to be its own project, or, heaven forbid, work with nova-networking, we could do that without changing our design much. | 23:35 |
| blogan | well, neutron would need to support some items being updateable through their API that is not currently supported | 23:35 |
| sbalukoff | We'd just be taking on additional responsibility serviceing the user API, and providing for an end-point for vendors to plug into (ie. in the same place they do now with the current Neutron LBaaS) | 23:36 |
| sbalukoff | Yep-- that's what the neutron-shim is for. | 23:36 |
| sbalukoff | (And, then, I suppose we'd also have a nova-networking shim.) | 23:36 |
| blogan | oh yeah | 23:36 |
| blogan | would you be opposed to this v2 going into a neutron incubation repo? | 23:37 |
| sbalukoff | It's just frustrating to get to this point now, after we've put months of work into improving Neutron LBaaS. | 23:37 |
| dougwig | wouldn't octavia become a driver of some other neutron lbaas spin out? it's the wrong model for most vendors. | 23:38 |
| blogan | sbalukoff: true but it doesn't mean its just gong to be trashed | 23:38 |
| sbalukoff | I would not. I know Blue Box would use it anyway. | 23:38 |
| sbalukoff | I suspect HP won't like this. | 23:38 |
| sbalukoff | As they have stricter requirements around meeting the "OpenStack" brand. | 23:38 |
| blogan | dougwig: yeah i hope octavia could have a driver for any openstack lbaas project | 23:39 |
| sbalukoff | blogan: That is certainly true. It hasn't been wasted effort. But it's certainly required us to jump through hoops we wouldn't have had to. (Like even considering back-ward compatibility with the Neutron LBaaS v1 api) | 23:39 |
| sbalukoff | dougwig: Yes. That's what I think we all want in any case. | 23:40 |
| blogan | true about HP, but Octavia isn't in openstack but we will push for it, and if lbaas v2 goes into a neutron sanctioned incubator, it probably has a better chance of getting into openstack than Octavia | 23:40 |
| blogan | sbalukoff: that is true, and me rushing to meet a deadline so making sacrifices | 23:40 |
| sbalukoff | blogan: Yep! | 23:41 |
| dougwig | i'm not entirely convinced that each of these spinout extensions needs its own api/daemon/authentication and loses access to the neutron db, either. seems like a shit ton of duplicated plumbing. | 23:41 |
| blogan | dougwig: i'm not either, but the only thing that convinces me more and more is the limitations of the extension loading | 23:42 |
| sbalukoff | dougwig: I'm not entirely against the idea that a "neutron shim" becomes the canonized way of handling stuff that isn't exposed via the public neutron API. But I suspect the Neutron devs won't like it. | 23:42 |
| sbalukoff | It's also more of a pain because unless the functionality is exposed via a public API, then internal changes to Neutron can easily break the shim (and sometimes in ways that are a pain to fix.) | 23:43 |
| dougwig | i'm talking about the front-facing API, CLI, keystone endpoints. the whole mess. | 23:43 |
| sbalukoff | dougwig: That's what I'm talking about, too. | 23:43 |
| blogan | spinning out would require keystone integration, cli's, api redefining and multiprocess/threading | 23:43 |
| dougwig | blogan: that's the conventional wisdom that i'm challenging. | 23:44 |
| blogan | dougwig: i know and i'm saying i agree that is a huge issue, but then why isn't there an oslo api library | 23:45 |
| sbalukoff | blogan: You make it seem so easy. ;) | 23:45 |
| blogan | and oslo keystone (maybe there is i dont know) | 23:45 |
| dougwig | does it really make sense for openstack to have top-level projects that are lbaas, vpn, firewall, insertion, servicevm, gbp, ... and the list goes on? | 23:46 |
| sbalukoff | dougwig: Isn't everything just glue anyway? | 23:46 |
| dougwig | there's glue. and then there's glue. | 23:46 |
| sbalukoff | Heh! | 23:46 |
| *** mlavalle has quit IRC | 23:47 | |
| sbalukoff | There are a bazillion stackforge projects. | 23:47 |
| blogan | to me, if hp, rackspace, bluebox have lbaas as a separate project, then it makes sense to me to have lbaas as a separate lbaas project | 23:47 |
| sbalukoff | I don't really have a problem with having a lot of stuff in the catalog. :/ | 23:47 |
| sbalukoff | blogan: Indeed! | 23:48 |
| blogan | but for the reasons stated above, it is a huge amount of overhead to get it spun out | 23:48 |
| sbalukoff | Hence the reason there are companies that specialize in doing this exactly. ;) | 23:49 |
| sbalukoff | But! | 23:49 |
| sbalukoff | As things mature, it generally gets easier to do. | 23:49 |
| sbalukoff | And isn't there a project to make installing OpenStack easier? | 23:49 |
| sbalukoff | (OOO or something?) | 23:49 |
| dougwig | right. which is why, if you've got extensions today, you soft spin-out and stay under neutron, then when oslo catches up, spin out for realsies. maybe it's just my hatred of that much duplication. | 23:50 |
| sbalukoff | Well, it could be said that most modern operating systems are just a collection of a bunch fo disparate parts, and that the OS itself is just the packaging and glue around all these parts. | 23:51 |
| sbalukoff | Why should OpenStack (you know, being a cloud "OS") be any different? | 23:51 |
| sbalukoff | It's just that our installer sucks right now. ;) | 23:52 |
| dougwig | i don't think you'll find that many unix utilities that implement the exact same style rest api server + cli +migration + etc, all with different code. | 23:52 |
| sbalukoff | Heh! That is true. | 23:53 |
| sbalukoff | Right. | 23:53 |
| sbalukoff | So, you're saying, we need something analogous to a core set of libraries everyone can draw upon for common shit. | 23:53 |
| *** mlavalle has joined #openstack-lbaas | 23:53 | |
| sbalukoff | A 'libc' for OpenStack. | 23:53 |
| sbalukoff | So, there's actually a thread which touches on similar points going on on the mailing list right now. | 23:54 |
| dougwig | oslo, as it were. with a unified client, cli, rest server framework, rpc framework, etc. | 23:54 |
| sbalukoff | Mostly, it's about how projects are pretty insular, and there are few people who have the 'big picture' who would be qualified to point out where different projects could combine forces. | 23:55 |
| sbalukoff | Oh-- sorry, I thought oslo was essentially a wrapper around RabbitMQ. | 23:55 |
| blogan | no oslo is where common code would go | 23:55 |
| sbalukoff | Ok. | 23:56 |
| blogan | such as db, config, rpc, etc | 23:56 |
| *** vivek-ebay has quit IRC | 23:56 | |
| blogan | but a unified client is in the works | 23:56 |
| blogan | i haven't heard anything about a unified rest server framework, probably because one framework can't be agreed upon | 23:57 |
| dougwig | i'd guess we're at least a year off from having all the goo unified. and spinning out a dozen sub projects right now would mean they all write their own goo. | 23:57 |
| dougwig | last summit i heard that pecan had been standardized on. eventlet was still being debated. | 23:57 |
| sbalukoff | You're talking about Neutron specifically. | 23:57 |
| blogan | dougwig: for oslo to have the things we need, i'd say quite a bit longer | 23:57 |
| dougwig | it was a generous "at least" | 23:58 |
| blogan | i've heard that too about pecan, but seeing is believing on that | 23:58 |
| dougwig | barbican uses it, at least. | 23:58 |
| blogan | yeah and neutron has plans to refactor to use it | 23:58 |
| blogan | but one way to really make it standard is for oslo to create the library for it | 23:59 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!