| *** xgerman has quit IRC | 00:10 | |
| *** sbfox has quit IRC | 00:10 | |
| *** VijayB has quit IRC | 00:12 | |
| *** VijayB_ has joined #openstack-lbaas | 00:21 | |
| *** jorgem has quit IRC | 00:36 | |
| *** crc32 has quit IRC | 00:40 | |
| *** dlundquist has left #openstack-lbaas | 00:54 | |
| *** magesh has quit IRC | 01:36 | |
| *** VijayB_ has quit IRC | 01:53 | |
| *** Krast_ has quit IRC | 02:26 | |
| *** Krast has joined #openstack-lbaas | 02:26 | |
| *** sbalukoff has quit IRC | 02:26 | |
| *** vjay4 has quit IRC | 02:44 | |
| *** woodster_ has quit IRC | 02:45 | |
| *** fnaval has quit IRC | 02:46 | |
| *** fnaval has joined #openstack-lbaas | 03:06 | |
| *** fnaval has quit IRC | 03:06 | |
| *** markmcclain has quit IRC | 03:24 | |
| *** amotoki has joined #openstack-lbaas | 03:33 | |
| *** orion_ has joined #openstack-lbaas | 03:47 | |
| *** vjay4 has joined #openstack-lbaas | 04:30 | |
| *** sbalukoff has joined #openstack-lbaas | 05:07 | |
| *** orion_ has quit IRC | 05:07 | |
| *** orion_ has joined #openstack-lbaas | 05:08 | |
| *** Krast has quit IRC | 05:08 | |
| *** orion_ has quit IRC | 05:12 | |
| *** ctracey has quit IRC | 05:16 | |
| *** ctracey has joined #openstack-lbaas | 05:20 | |
| *** vjay4 has quit IRC | 05:54 | |
| *** orion_ has joined #openstack-lbaas | 05:59 | |
| *** orion_ has quit IRC | 06:03 | |
| *** Krast has joined #openstack-lbaas | 06:14 | |
| *** Krast has quit IRC | 06:28 | |
| *** vjay4 has joined #openstack-lbaas | 06:52 | |
| *** jschwarz has joined #openstack-lbaas | 07:01 | |
| *** vjay4 has quit IRC | 07:04 | |
| *** sbfox has joined #openstack-lbaas | 07:11 | |
| *** vjay4 has joined #openstack-lbaas | 07:27 | |
| *** Krast has joined #openstack-lbaas | 08:22 | |
| *** sbfox has quit IRC | 09:01 | |
| *** jschwarz_ has joined #openstack-lbaas | 09:15 | |
| *** jschwarz has quit IRC | 09:15 | |
| *** jschwarz_ has quit IRC | 09:23 | |
| *** jschwarz_ has joined #openstack-lbaas | 10:03 | |
| *** vjay5 has joined #openstack-lbaas | 10:04 | |
| *** vjay4 has quit IRC | 10:07 | |
| *** Krast has quit IRC | 12:02 | |
| *** amotoki has quit IRC | 13:03 | |
| *** vjay5 has quit IRC | 13:14 | |
| *** woodster_ has joined #openstack-lbaas | 13:15 | |
| *** vjay5 has joined #openstack-lbaas | 13:28 | |
| *** HenryG_ has joined #openstack-lbaas | 13:46 | |
| *** HenryG has quit IRC | 13:47 | |
| *** HenryG_ is now known as HenryG | 14:07 | |
| *** markmcclain has joined #openstack-lbaas | 14:07 | |
| *** enikanorov__ has joined #openstack-lbaas | 14:09 | |
| *** enikanorov has quit IRC | 14:10 | |
| *** orion__ has joined #openstack-lbaas | 14:15 | |
| *** sbfox has joined #openstack-lbaas | 14:20 | |
| *** sbfox has quit IRC | 14:31 | |
| *** mestery_afk is now known as mestery | 14:39 | |
| *** markmcclain has quit IRC | 14:52 | |
| *** markmcclain has joined #openstack-lbaas | 14:53 | |
| *** mestery is now known as mestery_afk | 15:01 | |
| *** xgerman has joined #openstack-lbaas | 15:09 | |
| *** markmcclain has quit IRC | 15:12 | |
| *** jschwarz_ has quit IRC | 15:19 | |
| *** jorgem has joined #openstack-lbaas | 15:19 | |
| *** sbfox has joined #openstack-lbaas | 15:36 | |
| *** mestery_afk has quit IRC | 15:39 | |
| *** rohara has quit IRC | 15:55 | |
| *** rohara has joined #openstack-lbaas | 16:03 | |
| *** sbfox has quit IRC | 16:04 | |
| *** sbfox has joined #openstack-lbaas | 16:04 | |
| *** vjay5 has quit IRC | 16:06 | |
| dougwig | blogan, sbalukoff, xgerman: you around? | 16:30 |
|---|---|---|
| rm_work | blogan isn't at his computer but I could tell him to look | 16:31 |
| rm_work | dougwig: ^^ | 16:32 |
| dougwig | nothing urgent. want to pick their brains on v1/v2 incubator. | 16:32 |
| *** markmcclain has joined #openstack-lbaas | 16:34 | |
| blogan | dougwig: im going to food trucks, will bb in like 20 mins | 16:34 |
| dougwig | yeah, i'd skip me for food trucks too. | 16:35 |
| sbalukoff | dougwig: I'm here. | 16:36 |
| sbalukoff | Also, good morning! | 16:37 |
| dougwig | morning! | 16:37 |
| dougwig | just wanted to try and understand the desire to kick v1 into the incubator. seems like that would cause issues with users, given that it's been in-tree for so long. and it's not like it's going to change in the incubator. | 16:38 |
| dougwig | ? | 16:38 |
| sbalukoff | Well, part of that is because if v1 were released today, it certainly wouldn't pass muster to get through graduation. Part of that is my desire to see it retired / deprecated as soon as possible, since the longer it remains, the harder it's going to be to get v2 in place. | 16:39 |
| dougwig | sure. but if we assume the incubator exists to promote rapid evolution... v1 will never evolve. it's unlikely to ever have even a single commit against it ever again. and it's going to deprecate just as fast as v2 is ready. so... it gains what, beyond confusing end users? | 16:40 |
| sbalukoff | Also, part of that is my opinion that anything above l2/l3 really ought to be a separate sub-project that isn't rolled into Neutron core at all-- these should all be part of a master "Networking" project... | 16:41 |
| sbalukoff | And I'd love to see that happen (at all) | 16:41 |
| dougwig | it gains the devs nothing. it gains the users less than nothing. | 16:41 |
| dougwig | right, but that's not what the incubator is. | 16:41 |
| sbalukoff | It sends a clear signal to users that "you should not be using this." | 16:42 |
| dougwig | but they already are! | 16:42 |
| dougwig | the incubator isn't for sending political signals. | 16:42 |
| sbalukoff | HAHAHA! | 16:43 |
| sbalukoff | Suuuure it isn't. | 16:43 |
| sbalukoff | :P | 16:43 |
| dougwig | sigh. i'm trying approach with good faith, remember? | 16:43 |
| sbalukoff | I know you are. I'm having serous trouble with that. | 16:43 |
| dougwig | with me acting in good faith? ;-) | 16:44 |
| dougwig | (jk) | 16:44 |
| sbalukoff | No, with me trying to be that optimistic. | 16:44 |
| sbalukoff | ;) | 16:44 |
| sbalukoff | Seriously, though-- I have a hard time seeing this as anything but politics. | 16:45 |
| sbalukoff | I would be willing to settle for v1 being deprecated in Juno. | 16:46 |
| sbalukoff | I think v1 is going to be a major barrier to LBaaS spinning out. | 16:47 |
| sbalukoff | And really... it should spin out and become Openstack LBaaS. | 16:47 |
| sbalukoff | (The sooner that happens, the better.) | 16:48 |
| dougwig | i can see a number of scenarios where v1 doesn't get in the way of a spinout. but really, aren't we supposed to be not focusing on a spinout right now? | 16:48 |
| dougwig | let's write some dang code. | 16:48 |
| dougwig | the politics aren't going anywhere. | 16:48 |
| sbalukoff | dougwig: Sure. But the window for doing something to get v1 out of the way is also in front of us right now. | 16:49 |
| sbalukoff | And if we're being screwed with our efforts on v2 (which we absolutely are), then I'd like to see them throw us a bone and make it simpler for us to get v1 out of the way. | 16:49 |
| dougwig | it can be gotten rid of whenever we want. doing so before there's an alternative is silly. | 16:49 |
| *** markmcclain has quit IRC | 16:49 | |
| xgerman | hi | 16:55 |
| *** markmcclain has joined #openstack-lbaas | 16:55 | |
| xgerman | My argument is that the reference driver is unusable so for me that shouldn't be in neutron | 16:56 |
| xgerman | but if we pull the reference driver the rest likely needs to go, too - so I am not sure which is the lesser evil... | 16:57 |
| *** vjay5 has joined #openstack-lbaas | 17:08 | |
| blogan | dougwig I see your point and it makes sense, that was my initial thinking, and your reasons are probably why it will not go into the incubator | 17:10 |
| blogan | but I guess my reason is that if v1 wasn't already in tree, then wouldn't it belong in the incubator? | 17:11 |
| dougwig | it would, no question. | 17:11 |
| blogan | or really i suppose it wouldn't belong anywhere since v2 is already in there | 17:11 |
| blogan | so yeah I guess from the viewpoint of doing the right thing for neutron users and current lbaas users, pulling it out of tree would not be right | 17:12 |
| blogan | i suppose it would just be a political maneuver | 17:12 |
| dougwig | v2 needs horizon and docs and a full test suite before i'd consider it to be "already in there" (i'd overlook no agent.) | 17:15 |
| sbalukoff | I'd be willing to settle for a deprecated v1 API, so that we can get rid of that piece of shit earlier. ;) | 17:15 |
| dougwig | tell us how you really feel. don't sugar coat it. | 17:16 |
| blogan | its gonig to need the agent to get graduated anyway | 17:16 |
| sbalukoff | HAHA | 17:16 |
| blogan | the right thing to do for the end users is to deprecate it once v2 is graduated | 17:17 |
| blogan | or is spun out | 17:17 |
| sbalukoff | I'm not sure I agree with that. | 17:17 |
| blogan | you have the floor sir | 17:17 |
| dougwig | blogan: i was referring to what i'd need to see to see it as parity with the current state of v1. | 17:17 |
| xgerman | and an audience - i am back from our huddle | 17:17 |
| sbalukoff | Right, so v1 is all but unusuable for most production uses. And v2 *in its current state* can provide all the functionality of v1. | 17:18 |
| xgerman | sbalukoff, the v1 reference driver | 17:18 |
| dougwig | blogan: +1 on the right timing is when v2 is ready to replace, though i'd be good with pre-graduation on that. right now feels too soon. | 17:18 |
| blogan | sbalukoff: it really can't because it doesn't have the driver support, nor an agent to allow for a scalable reference implementation | 17:18 |
| dougwig | sbalukoff: not everyone is a huge operator with their own UI. no horizon support is a big deal. no docs is a big deal. no real test suite is a big deal. | 17:19 |
| sbalukoff | v1 has a scalable reference implementation? | 17:19 |
| xgerman | dougiwg, now as our souls are crushed we waon;'t work hard to get it into juno | 17:19 |
| dougwig | xgerman: no question, our mo' got killed. | 17:19 |
| sbalukoff | Well, if we had somewhere to work on that... all those things would be taken care of pretty quickly. | 17:19 |
| blogan | scalable in the sense you can put the agent on as many nodes as you want | 17:19 |
| sbalukoff | But incubator is also still a pipe-dream right now. | 17:19 |
| xgerman | no docs is wrong. Min wrote all the docs for v2 | 17:19 |
| dougwig | sbalukoff: yes, in a way. you can run as many haproxy boxes as you want, each with their own agent. | 17:20 |
| *** sbfox has quit IRC | 17:20 | |
| xgerman | In my opinion v1 works well with hardware load balancers. We had to pull v1 out of Helion because it absolutely doesn't work even in small installations | 17:21 |
| sbalukoff | dougwig: Really? And users manipulating the v1 API would result in some kind of scale when running multiple agents on multiple hosts? | 17:21 |
| dougwig | yeah, there's a crude scheduler that maps your root object and children to a particular node. | 17:22 |
| dougwig | no HA, no provisions for moving when overloaded. it's not a good scalable solution, it viewed sideways, it is. | 17:22 |
| xgerman | so as I said I would love to pull the referewnce implementation + leave the API | 17:23 |
| xgerman | is that an option? | 17:23 |
| sbalukoff | dougwig: It sounds to me like people using v1 (what poor few there are) are doing things not exactly documented anyway. :/ | 17:24 |
| sbalukoff | And making hack-ish alterations to "make it work." | 17:24 |
| dougwig | sbalukoff: you just described all of openstack. :) | 17:24 |
| *** dlundquist has joined #openstack-lbaas | 17:24 | |
| *** sbfox has joined #openstack-lbaas | 17:24 | |
| *** markmcclain has quit IRC | 17:25 | |
| *** markmcclain has joined #openstack-lbaas | 17:25 | |
| sbalukoff | dougwig: Haha! Good point. | 17:29 |
| dougwig | going to grab lunch, bbiab. | 17:29 |
| sbalukoff | Sorry for the grumpiness folks. I woke up on the wrong side of the bed last week (and called it "incubator") | 17:30 |
| blogan | xgerman: i don't think thats an option because everything needs a reference implementation to exist | 17:31 |
| sbalukoff | blogan: +1 | 17:31 |
| xgerman | well, the reference implementation would be in the incubator... so... | 17:32 |
| blogan | yeah but then the reference implemenation would be installed in a different manner | 17:32 |
| blogan | so i doubt that is an option | 17:32 |
| sbalukoff | We've also been told that apparently some users somewhere are using the v1 reference implementation in production (the poor schmucks) | 17:32 |
| sbalukoff | Well... | 17:33 |
| blogan | well octavia will solve all their problems then right? | 17:33 |
| xgerman | Octavia will also heal unicorns | 17:33 |
| sbalukoff | dougwig does have a good point: Pulling v1 into incubator would be a dick move to those users who actually use it. | 17:33 |
| sbalukoff | Correction: Octavia will shoot unicorns. | 17:33 |
| sbalukoff | Out of canons. | 17:33 |
| blogan | can it shoot then heal? | 17:33 |
| sbalukoff | Yes. | 17:34 |
| sbalukoff | That's its version of tough love. | 17:34 |
| blogan | its good testing | 17:34 |
| blogan | oh yeah sbalukoff | 17:34 |
| blogan | you have said listeners will have many pools | 17:35 |
| sbalukoff | blogan: They will... once we have L7 functionality. | 17:35 |
| blogan | is that changing from the neutron lbaas model where the L7 object was going to have a pool | 17:35 |
| sbalukoff | Er... | 17:35 |
| blogan | what I mean is will the listener directly have a one to many relationship with pools or will it be indirectly through an L7 object? | 17:36 |
| sbalukoff | So, listeners will have many pools. These get linked to the listener object through L7 policies (or, as a default_pool_id) | 17:36 |
| sbalukoff | Indirectly. | 17:36 |
| sbalukoff | Well, a join table is necessary in either case. The L7 policy just has some extra attributes. | 17:36 |
| blogan | okay so in that case it's still fine to have an API look like /loadbalancers/{lb_id}/listeners/{listenr_id}/pools | 17:37 |
| sbalukoff | (Sorry, I often think of these things in terms of their database representations.) | 17:37 |
| blogan | perfectly fine, im thinking about them in both the database and api | 17:37 |
| sbalukoff | blogan: Yes. But! | 17:37 |
| sbalukoff | It occurs to me... | 17:37 |
| sbalukoff | With the listener having a 'default_pool_id' attribute, this implies that the default action for the listener is to forward the request on to a back-end pool. | 17:37 |
| *** VijayB has joined #openstack-lbaas | 17:38 | |
| sbalukoff | This is valid for >90% of load balancers out there... | 17:38 |
| sbalukoff | But! Occasionally the default action will be to redirect or block. | 17:38 |
| blogan | yeah | 17:38 |
| blogan | i think that can just be a validation piece | 17:38 |
| blogan | bc the listener is going to have to have some kind of redirect or block attribute for these features right? | 17:38 |
| sbalukoff | That can currently be accomplished by making an L7 rule which catches everyting (eg. "Search the header for "Host" and match anything). That would effectively supersede a default "forward request to pool X" action... | 17:39 |
| sbalukoff | But it's rather circumspect. | 17:39 |
| sbalukoff | Do y'all think that's worth revisiting? | 17:39 |
| sbalukoff | What I mean by that is... the default action a listener takes could/should be any kind of action that an L7 policy could take. | 17:40 |
| blogan | so why don't we just call the listener's pool by pool_id | 17:41 |
| blogan | so it's not implying a default action | 17:41 |
| sbalukoff | Does it make sense to say that instead of a default_pool_id to forward to... that there should be a default L7 policy, and that what action that policy takes can be variable... | 17:41 |
| sbalukoff | Or is that just too confusing for most users? | 17:41 |
| blogan | i think that will get too confusing | 17:41 |
| xgerman | +1 | 17:41 |
| sbalukoff | So, callinging the listener's pool by pool ID implies the default action is to forward to that pool. | 17:41 |
| blogan | yeah | 17:42 |
| sbalukoff | My point was that sometimes, you really just want to redirect. | 17:42 |
| blogan | and that redirect would happen in the L7 rules correct? | 17:42 |
| sbalukoff | (Going back to that relatively common scenario discussed on the mailing list where you can have a listener without a pool.) | 17:42 |
| sbalukoff | blogan: Presently, yes. | 17:42 |
| sbalukoff | It's a bit of a hack, and I don't have a problem telling users how to do it as long as it's well documented. | 17:43 |
| sbalukoff | But... part of the implication here is that it needs to be considered a valid configuration if a listener has no pool. | 17:43 |
| blogan | see i think https redirect should actually be less confusing as an attribute of the listener, but it wouldn't be consistent | 17:43 |
| blogan | s/should/would | 17:44 |
| sbalukoff | blogan: That's actually how we do it in our model right now: If you're going to be doing an https redirect, there's a field on the listener object you can fill out with the URL you want to redirect too... and if that field is not empty, then the software knows it shouldn't look for a back-end pool. | 17:44 |
| sbalukoff | I was just musing "is there a better way to do this?" | 17:45 |
| *** vjay5 has quit IRC | 17:45 | |
| blogan | i feel like that way is better | 17:45 |
| sbalukoff | Also, it's conceivable that a user might want a default action to be redirect, but that some URLs would actually be served directly. We don't have anyone doing this right now... but in any case, leaving things as they are (with the L7 hackish way of doing a redirect) could accommodate this as well. | 17:46 |
| blogan | but then the other use cases for L7 would be inconsistent with that | 17:46 |
| sbalukoff | blogan: I'm not against it. :) | 17:46 |
| sbalukoff | So... | 17:47 |
| sbalukoff | The way I try to approach these things is to make things easiest for the most common usage scenarios. | 17:47 |
| *** jschwarz has joined #openstack-lbaas | 17:47 | |
| blogan | so i guess it coudl be as simple as if these things are very common across users then we can make an attribute of a listener | 17:47 |
| sbalukoff | But still accommodate advanced and somewhat screwey-looking configurations if the user can justify a reason for wanting them. | 17:47 |
| blogan | i am fine with this | 17:47 |
| *** crc32 has joined #openstack-lbaas | 17:47 | |
| dougwig | I want a unicorn. | 17:48 |
| blogan | if we're not allowing sharing of pools, and a user wants two different L7 rules to direct traffic to the same pool, we are fine with having them create two duplicate pools right? | 17:49 |
| sbalukoff | dougwig: I shall get you a unicorn. | 17:49 |
| * blogan grills a unicorn steak for dougwig | 17:49 | |
| sbalukoff | That's finger-licking good! | 17:49 |
| sbalukoff | blogan: As I understand it, yes we are. | 17:49 |
| sbalukoff | Unless users come to us and complain loudly. | 17:50 |
| blogan | yeah and then it'll be easier to go to sharing of pools rather than the other direction | 17:50 |
| blogan | will still be a complicated thing though | 17:50 |
| sbalukoff | Yeah. | 17:50 |
| blogan | you got an idea for a meeting agenda tomorrow? | 17:51 |
| sbalukoff | blogan: I was going to put that together once this conversation is over. I think I've only got 1 or 2 items on it, so if you want to add more, feel free! | 17:52 |
| sbalukoff | blogan: | 17:52 |
| sbalukoff | What do you think of allowing sharing of pools within one listener configuration? | 17:52 |
| sbalukoff | But not between listeners? | 17:52 |
| sbalukoff | In theory, we could still have "simple" status and stats. | 17:52 |
| sbalukoff | And we wouldn't be forcing haproxy to do a bunch of duplicate health checks. | 17:53 |
| sbalukoff | And, since we don't presently allow for complicated logic around L7 rules... that could increase the number of pools a user would have to use artificially. | 17:53 |
| sbalukoff | What would be the possible down-sides of that? | 17:54 |
| sbalukoff | Hmmm... | 17:54 |
| xgerman | the health check argument could be extended to our discussion with listeners and haproxies -- just saying :-) | 17:55 |
| sbalukoff | All the pools could still be accessed via a /loadbalancers/{lb_id}/listeners/{listenr_id}/pools/{pool_id} URL... we'd just add a 'default' attribute to one of them. :) | 17:56 |
| blogan | wouldn't that be the listeners default_pool_id | 17:56 |
| blogan | or pool_id | 17:56 |
| sbalukoff | xgerman: That's true. Though I think the incidence of duplicate checks would be far more with non-shared pools given the way L7 is meant to work. | 17:57 |
| sbalukoff | blogan: Aah-- yes, you're right. | 17:57 |
| sbalukoff | That's a better way of doing it. | 17:57 |
| sbalukoff | Sorry, I was thinking if we disallowed sharing of pools between listeners, then pools could have a listener_id attribute. | 17:57 |
| blogan | if listeners had a direct one to many with pools that would be the case | 17:58 |
| sbalukoff | (Rather, they *would* probably need that attribute. | 17:58 |
| sbalukoff | blogan: So that's what I'm saying, have a direct one-to many, but we don't do anything with pools that aren't either the default pool, or referenced by an L7 rule. | 17:58 |
| blogan | im kinda thinking sharing pools within listener configuration might be okay | 17:59 |
| sbalukoff | Yeah, I'm trying to think of down-sides to this. | 17:59 |
| sbalukoff | Again, stats collection and status would actually probably be easier for the user... | 17:59 |
| *** VijayB has quit IRC | 17:59 | |
| sbalukoff | Hmmm.... | 17:59 |
| sbalukoff | Pools would still be referenced through their parent (listener) end-point... | 18:00 |
| blogan | i remember drawing something similar like that up during the whole api proposal phase but didn't do it for some reason | 18:01 |
| sbalukoff | Much simpler for users with complicated load balancer configurations while not increasing complexity for users with simple configurations... | 18:01 |
| sbalukoff | Seriously, what's the achilles heel with this idea? | 18:02 |
| blogan | ok just to be clear here, you'r suggesting listener_id attribute on the pool to give the listener to pool a direct one-to-many, while also having a default_pool attribute on the listener? | 18:02 |
| blogan | or the pool would just have a default attribute? | 18:02 |
| xgerman | well, the achilles heal is that if we ever get to shareable pools as demanded by some vendors we will have to adapt | 18:02 |
| sbalukoff | blogan: either a default_pool_id on the listener, or a 'default' attribute on the pool. The former seems more intuitive and less error-prone. | 18:02 |
| sbalukoff | One can assume the first pool added will be the default. | 18:03 |
| xgerman | never assume | 18:03 |
| blogan | lol | 18:03 |
| sbalukoff | Haha | 18:03 |
| sbalukoff | xgerman: I think we'd have to adapt in either case. | 18:03 |
| blogan | i like the default_pool_id on the listener, however that also means we need to have a listener_id on the pool as well so that we know a pool belongs to a listener | 18:04 |
| *** VijayB_ has joined #openstack-lbaas | 18:04 | |
| sbalukoff | blogan: Yes. | 18:04 |
| jschwarz | jumping in: what's the idea of 'default_pool_id', then? | 18:04 |
| sbalukoff | That's how we enforce the 'no sharing pools between listeners' rule. | 18:05 |
| blogan | which without the assumption of first pool created is the default, then the user would have to create the listenr first, then the pool, then update the listener's default_pool_id | 18:05 |
| sbalukoff | jschwarz: A listener can have many pools (accessed via different L7 policies / rules). But only one of them can be the default, if no L7 policies match. | 18:05 |
| sbalukoff | blogan: Yes. | 18:05 |
| blogan | or the API just allows a default attribute on the pool, that will automatically markit as the listener's default_pool_id | 18:06 |
| blogan | but we don't store taht default attribut eanywhere else | 18:06 |
| sbalukoff | blogan: Even better. :) | 18:06 |
| blogan | so when I originally thought of havng the defualt attribute on the pool, we didn't do it because we were also sharing pools across many listeners | 18:07 |
| blogan | in this case it probably works | 18:07 |
| blogan | oh and we also weren't dong default_pool_id | 18:08 |
| blogan | on listener | 18:08 |
| sbalukoff | blogan: It does, but I still think the default_pool_id attribute is better. | 18:08 |
| sbalukoff | (on the listener) | 18:08 |
| blogan | yeah i think that will be perfectly fine | 18:08 |
| blogan | i say that now and then of course soemthing will pop up and we either hack around it or don't do it | 18:09 |
| sbalukoff | Doing the default_pool_id on the listener actually makes the coding changes slightly simpler, if at some future date we decide that we need to allow pools to be shared between listeners. | 18:09 |
| sbalukoff | Haha! | 18:09 |
| blogan | well if we start sharing pools across listeners, then it wouldn't make sense for pools to not be a top level object | 18:09 |
| sbalukoff | Right, but we can cross that bridge if we get forced, kicking and screaming, to go there. | 18:10 |
| blogan | im sure we can do some combination of both | 18:10 |
| sbalukoff | Haha! | 18:10 |
| blogan | instead of pools, they'll be called GLOBAL_POOLS!! | 18:10 |
| xgerman | awesome | 18:10 |
| blogan | or UNICORN_POOLS!!! | 18:10 |
| xgerman | Back to the ML where I am urged to go back to OpenStack school... | 18:11 |
| sbalukoff | Hmmm? I guess I need to catch up on that. | 18:12 |
| blogan | whats up on the ML? | 18:13 |
| xgerman | I said I don't like sudden changes and I have been sent to "upstream training" | 18:14 |
| blogan | lol sounds like reducation camp | 18:15 |
| blogan | re-education | 18:15 |
| xgerman | yep, that's the offense I take :-) | 18:15 |
| sbalukoff | Heh! | 18:16 |
| *** sbfox has quit IRC | 18:18 | |
| *** sbfox has joined #openstack-lbaas | 18:18 | |
| sbalukoff | Oh yeah, Stefano. | 18:22 |
| sbalukoff | The same guy who wrote the blog article about how only developers should be submitting things to launchpad and gerrit. | 18:23 |
| sbalukoff | Great guy. :P | 18:23 |
| sbalukoff | http://maffulli.net/2014/07/14/only-developers-should-file-specifications-and-blueprints/ | 18:26 |
| *** jschwarz has quit IRC | 18:38 | |
| *** sbfox has quit IRC | 18:47 | |
| *** ptoohill has joined #openstack-lbaas | 18:52 | |
| *** orion___ has joined #openstack-lbaas | 18:58 | |
| *** orion___ has quit IRC | 18:59 | |
| *** orion___ has joined #openstack-lbaas | 19:00 | |
| *** ptoohill has quit IRC | 19:00 | |
| *** orion__ has quit IRC | 19:02 | |
| *** orion__ has joined #openstack-lbaas | 19:03 | |
| *** orion___ has quit IRC | 19:03 | |
| *** sbfox has joined #openstack-lbaas | 19:11 | |
| *** markmcclain has quit IRC | 19:17 | |
| *** sbfox has quit IRC | 19:20 | |
| *** markmcclain has joined #openstack-lbaas | 19:50 | |
| *** VijayB_ has quit IRC | 19:50 | |
| *** VijayB has joined #openstack-lbaas | 20:22 | |
| *** orion__ has quit IRC | 20:25 | |
| *** orion__ has joined #openstack-lbaas | 20:26 | |
| *** orion__ has quit IRC | 20:30 | |
| *** orion__ has joined #openstack-lbaas | 20:30 | |
| *** Youcef has quit IRC | 20:44 | |
| *** mestery has joined #openstack-lbaas | 20:49 | |
| *** mestery has quit IRC | 20:49 | |
| *** mestery has joined #openstack-lbaas | 20:50 | |
| *** orion__ has quit IRC | 20:57 | |
| *** orion__ has joined #openstack-lbaas | 20:58 | |
| *** orion__ has quit IRC | 20:59 | |
| *** orion__ has joined #openstack-lbaas | 20:59 | |
| *** VijayB has quit IRC | 21:21 | |
| *** dlundquist has left #openstack-lbaas | 21:28 | |
| *** orion__ has quit IRC | 21:29 | |
| *** orion_ has joined #openstack-lbaas | 21:30 | |
| *** crc32 has quit IRC | 21:31 | |
| *** VijayB_ has joined #openstack-lbaas | 21:32 | |
| sbalukoff | Octavia meeting agenda: https://wiki.openstack.org/wiki/Octavia/Weekly_Meeting_Agenda#Agenda | 21:33 |
| *** orion_ has quit IRC | 21:34 | |
| *** crc32 has joined #openstack-lbaas | 21:35 | |
| *** crc32 has quit IRC | 21:35 | |
| *** mestery_ has joined #openstack-lbaas | 21:36 | |
| blogan | sbalukoff: I know we need some consensus on a few things, but I think creating the skeleton code/interfaces could be something we can do as action items per the last bullet point | 21:37 |
| *** mestery has quit IRC | 21:37 | |
| blogan | and actually writing implementations where it makes sense | 21:37 |
| blogan | if it makes sense | 21:38 |
| blogan | oh yeah this needs some +2s | 21:38 |
| blogan | https://review.openstack.org/#/c/114730/ | 21:38 |
| sbalukoff | Also, we should probably ask people to review your initial migrations (something I was going to do this afternoon.) | 21:38 |
| sbalukoff | Yes | 21:38 |
| sbalukoff | That. :) | 21:38 |
| blogan | thats not the migrations | 21:39 |
| sbalukoff | Oh, not that. | 21:39 |
| sbalukoff | Yes, you're right, that one does need some +2's. | 21:39 |
| blogan | bc the migration is a WIP and i'll be updating it based on what is decided in the meeting tomorrow | 21:39 |
| sbalukoff | Ok, sounds good. | 21:39 |
| sbalukoff | Would you like me to add those items to the agenda, or do you want to do that? | 21:39 |
| blogan | i'll let you do it | 21:39 |
| sbalukoff | Sounds good! | 21:40 |
| blogan | wiki markup can rot in hell | 21:40 |
| *** mestery_ is now known as mestery | 21:40 | |
| blogan | bc there's 50,000 versions | 21:40 |
| sbalukoff | Haha! Indeed. I think this is mediawiki, though... so it's probably the most commonly used one. | 21:40 |
| blogan | well when i've got 2 or 3 internal ones that are different, and one external...they all seem as commonly used | 21:41 |
| sbalukoff | https://review.openstack.org/#/c/113458/ --> That's the v0.5 design. | 21:45 |
| sbalukoff | I'd like to see this ratified in the next week or so so we have... less of a moving target that we can start coding. :) | 21:45 |
| *** crc32 has joined #openstack-lbaas | 21:45 | |
| *** mestery has quit IRC | 21:45 | |
| *** mestery has joined #openstack-lbaas | 21:46 | |
| blogan | fine by, as long as the expectation is that it did not cover the finer details and it is subject to change if crazy things crop up that we didn't think about | 21:47 |
| blogan | which im sure everyone is under the understanding | 21:47 |
| sbalukoff | Yep, that's my understanding, eh. | 21:47 |
| sbalukoff | It's also not set in stone... ratifying it is more of a good checkpoint to say "we think this is what it's going to look like" If someone has a major concern that comes up afterward, that doesn't mean we can't change it. | 21:48 |
| sbalukoff | (That'll be annoying, since we're trying to give everyone a window to comment... but it's not out of the question, eh.) | 21:48 |
| sbalukoff | dougwig: What are the interrim github repos for Octavia going to be used for? | 21:51 |
| sbalukoff | (Sorry, my git-fu is lacking, I know... I'm not sure what the utility of this is if we have full control on merging patches.) | 21:52 |
| sbalukoff | Longer-term, more extensive branches? | 21:52 |
| dougwig | just an idea, but we could pull the neutron lbaas v2 reviews into a few repos we control, and make it easier for people to pull down/setup/tweak. get 'em out of gerrit. | 21:52 |
| dougwig | octavia has stackforge, obviously. | 21:52 |
| dougwig | we can always turn those repos into the new gerrit reviews for the incubator. | 21:53 |
| sbalukoff | Aah... that's not a bad idea, eh. | 21:53 |
| dougwig | talk to the driver vendors, get them all using that as well, merge in tls/l7/etc. | 21:53 |
| sbalukoff | Prior to getting into incubator? | 21:53 |
| dougwig | one sec, let me check something. | 21:54 |
| sbalukoff | Or as a place to (in effect) stage code before we send it to incubator and try to get core reviewer time for a merge? | 21:54 |
| dougwig | someplace to get our mo' back while we wait. i just pinged kyle to check on timeframe, to see if it makes sense. | 21:55 |
| dougwig | was a random thought for discussion. not fully-baked. | 21:55 |
| xgerman | dougwig: Just as a process remark we only merge things into Octavia hen tow cores +2 | 21:56 |
| dougwig | err, did I +A accidentally? | 21:56 |
| xgerman | you did it right and I am blind | 21:57 |
| dougwig | heh, ok. you just read my mind, because since it was just typos, i *almost* +A'ed it directly. | 21:57 |
| dougwig | technically, you're supposed to wait 2-3 days between +2's as well, to give others time to comment. | 21:57 |
| dougwig | though i don't think that matters in this case. | 21:58 |
| xgerman | yep | 21:58 |
| sbalukoff | I totally just merged it. | 21:58 |
| dougwig | although i guess the +2 doesn't have to wait, just the +A. but it doesn't matter on a typos review. | 21:58 |
| sbalukoff | FWIW, I don't think we need to wait if it really is just typo fixes. :p | 21:58 |
| *** mestery has quit IRC | 22:01 | |
| xgerman | well, I +2 it so you can merge whenever you are ready :-) | 22:01 |
| sbalukoff | Also, I totally would not object if someone wants to flesh this out with more detail at some point: https://wiki.openstack.org/wiki/Octavia | 22:03 |
| sbalukoff | (Obviously, no rush.) | 22:03 |
| sbalukoff | So here's a question for y'all: When we arrive at conclusions to some of the "get consensus on" questions around implementation details, I would like to make sure these are docuemented somewhere. We will of course keep notes in the meeting minutes on these decisions, but thinking a year or two from now when we've made dozens of these kinds of decisions, I don't want to force newcomers to have to go through a year's worth | 22:15 |
| sbalukoff | of meeting minutes to try to piece together whether "decision A" was arbitrary, or whether we actually discussed it... in deciding whether it needs to change. | 22:15 |
| sbalukoff | So! | 22:15 |
| sbalukoff | I think this could potentially be documented either in the wiki, or right in the code repository itself. | 22:15 |
| sbalukoff | What do y'all think is the most appropriate place for this kind of stuff to be kept? | 22:16 |
| openstackgerrit | A change was merged to stackforge/octavia: Hacking fixes in CONSTITUTION, ROADMAP, & HACKING https://review.openstack.org/114730 | 22:16 |
| sbalukoff | (I think the wiki is friendlier to edit, but, living as it does apart from the code, it more vulnerable to someone's gratuituous cleanup efforts and/or restructuring of wiki documentation.) | 22:17 |
| *** HenryG_ has joined #openstack-lbaas | 22:17 | |
| sbalukoff | What do y'all think? | 22:18 |
| sbalukoff | (I can make this another, hopefully brief, agenda item if y'all like. ;) ) | 22:18 |
| xgerman | yeah, let's vote on it during the meeting | 22:18 |
| sbalukoff | Wiki might also be friendlier place to put summary data like benchmark results in documenting the reason for a particular decision. | 22:19 |
| sbalukoff | Ok. | 22:19 |
| *** HenryG has quit IRC | 22:19 | |
| xgerman | well, you cna also add rst files or similar to the source tree | 22:19 |
| xgerman | I have seen both working -- and don't really have a preference | 22:20 |
| sbalukoff | Yep. That's true. | 22:21 |
| dougwig | sbalukoff: wiki. it has a history button, and notifications. | 22:22 |
| xgerman | jenkins has a similar functionality :-) | 22:22 |
| dougwig | editing is a bit higher touch. | 22:22 |
| dougwig | and by a bit, i mean battleship sized. | 22:22 |
| sbalukoff | Haha | 22:22 |
| sbalukoff | I'm indifferent to where we put this stuff. I only insist that we put it somewhere that people can find it. :) | 22:23 |
| xgerman | +1` | 22:23 |
| *** markmcclain has quit IRC | 22:26 | |
| *** mestery has joined #openstack-lbaas | 22:53 | |
| *** jorgem has quit IRC | 23:01 | |
| *** mestery_ has joined #openstack-lbaas | 23:02 | |
| *** mestery has quit IRC | 23:02 | |
| *** mestery_ has quit IRC | 23:07 | |
| *** mestery has joined #openstack-lbaas | 23:07 | |
| *** mestery has quit IRC | 23:12 | |
| *** mestery has joined #openstack-lbaas | 23:13 | |
| *** vjay5 has joined #openstack-lbaas | 23:14 | |
| *** vjay5 has quit IRC | 23:33 | |
| *** mestery has quit IRC | 23:41 | |
| *** HenryG_ is now known as HenryG | 23:42 | |
| *** mestery has joined #openstack-lbaas | 23:44 | |
| *** mestery has quit IRC | 23:45 | |
| *** crc32 has quit IRC | 23:49 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!