| *** ducttape_ has quit IRC | 00:01 | |
| *** kevinbenton has quit IRC | 00:46 | |
| *** kobis has quit IRC | 00:47 | |
| *** armax has quit IRC | 00:48 | |
| *** kevinbenton has joined #openstack-lbaas | 00:50 | |
| *** fnaval has quit IRC | 00:56 | |
| *** kobis has joined #openstack-lbaas | 00:57 | |
| *** jidar has quit IRC | 01:00 | |
| *** SumitNaiksatam has quit IRC | 01:03 | |
| *** jidar has joined #openstack-lbaas | 01:04 | |
| *** doug-fish has quit IRC | 01:04 | |
| *** doug-fish has joined #openstack-lbaas | 01:05 | |
| *** doug-fish has quit IRC | 01:06 | |
| *** doug-fish has joined #openstack-lbaas | 01:06 | |
| *** kobis has quit IRC | 01:13 | |
| *** _cjones_ has quit IRC | 01:29 | |
| *** kobis has joined #openstack-lbaas | 01:47 | |
| *** bochi-michael has joined #openstack-lbaas | 01:59 | |
| bana_k | this change https://github.com/openstack/octavia/blob/master/octavia/db/migration/alembic_migrations/versions/43287cd10fef_make_pool_lb_algorithm_larger.py is giving trouble as algorithm table still has a length of 30 | 02:00 |
|---|---|---|
| bana_k | so if I try to update the algorithm table's name it throws me error saying its a foreign key | 02:02 |
| *** minwang2 has quit IRC | 02:03 | |
| bana_k | so was thinking of dropping the FK constraint n then doing those column updates and then adding back the FK | 02:04 |
| *** johnsom_ has quit IRC | 02:05 | |
| *** kobis has quit IRC | 02:15 | |
| *** kobis has joined #openstack-lbaas | 02:16 | |
| *** yamamoto_ has joined #openstack-lbaas | 02:18 | |
| *** doug-fish has quit IRC | 02:20 | |
| *** doug-fish has joined #openstack-lbaas | 02:21 | |
| *** doug-fish has quit IRC | 02:21 | |
| *** doug-fish has joined #openstack-lbaas | 02:21 | |
| *** kobis has quit IRC | 02:22 | |
| *** Tiancheng has joined #openstack-lbaas | 02:30 | |
| *** jwarendt has quit IRC | 02:36 | |
| *** yamamoto_ has quit IRC | 02:38 | |
| *** yamamoto_ has joined #openstack-lbaas | 02:39 | |
| *** bana_k has quit IRC | 02:44 | |
| *** woodster_ has quit IRC | 02:46 | |
| *** doug-fish has quit IRC | 02:50 | |
| *** yamamoto_ has quit IRC | 02:55 | |
| *** yuanying has quit IRC | 03:20 | |
| *** yuanying has joined #openstack-lbaas | 03:21 | |
| *** links has joined #openstack-lbaas | 03:26 | |
| *** links has quit IRC | 03:40 | |
| *** yamamoto_ has joined #openstack-lbaas | 03:47 | |
| *** links has joined #openstack-lbaas | 03:48 | |
| *** doug-fish has joined #openstack-lbaas | 03:50 | |
| *** yuanying has quit IRC | 03:55 | |
| *** yuanying has joined #openstack-lbaas | 03:57 | |
| *** doug-fish has quit IRC | 04:00 | |
| *** links has quit IRC | 04:04 | |
| *** links has joined #openstack-lbaas | 04:16 | |
| *** links has quit IRC | 04:27 | |
| *** links has joined #openstack-lbaas | 04:28 | |
| *** links has quit IRC | 04:50 | |
| *** links has joined #openstack-lbaas | 04:57 | |
| *** links has quit IRC | 05:13 | |
| *** kobis has joined #openstack-lbaas | 05:13 | |
| *** links has joined #openstack-lbaas | 05:21 | |
| *** bochi-michael has quit IRC | 05:27 | |
| *** bochi-michael has joined #openstack-lbaas | 05:27 | |
| *** doug-fish has joined #openstack-lbaas | 05:32 | |
| *** doug-fish has quit IRC | 05:32 | |
| *** links has quit IRC | 05:36 | |
| *** links has joined #openstack-lbaas | 05:37 | |
| *** armax has joined #openstack-lbaas | 05:37 | |
| *** kobis has quit IRC | 05:42 | |
| openstackgerrit | Gerard Braad proposed openstack/octavia: Fix typo in migration README.rst https://review.openstack.org/271146 | 05:50 |
| *** links has quit IRC | 05:59 | |
| *** links has joined #openstack-lbaas | 06:01 | |
| *** Tiancheng has quit IRC | 06:06 | |
| *** Tiancheng has joined #openstack-lbaas | 06:11 | |
| *** bana_k has joined #openstack-lbaas | 06:13 | |
| *** numans has joined #openstack-lbaas | 06:19 | |
| *** links has quit IRC | 06:22 | |
| *** links has joined #openstack-lbaas | 06:23 | |
| *** _cjones_ has joined #openstack-lbaas | 06:32 | |
| *** _cjones_ has quit IRC | 06:34 | |
| *** _cjones_ has joined #openstack-lbaas | 06:35 | |
| openstackgerrit | Gerard Braad proposed openstack/octavia: Fix typo in migration README.rst https://review.openstack.org/271146 | 06:45 |
| *** links has quit IRC | 06:46 | |
| *** links has joined #openstack-lbaas | 06:50 | |
| *** links has quit IRC | 07:09 | |
| *** links has joined #openstack-lbaas | 07:09 | |
| *** _cjones_ has quit IRC | 07:17 | |
| *** armax has quit IRC | 07:18 | |
| *** _cjones_ has joined #openstack-lbaas | 07:18 | |
| *** armax has joined #openstack-lbaas | 07:24 | |
| *** rcernin has joined #openstack-lbaas | 07:31 | |
| *** links has quit IRC | 07:31 | |
| *** armax has quit IRC | 07:43 | |
| *** idonotknow has joined #openstack-lbaas | 07:48 | |
| *** links has joined #openstack-lbaas | 07:48 | |
| idonotknow | Hi,everyone.Does anyone know why my loadbalancer is always on PENDING_UPDATE when I restart a vm manually. lbaasv2 | 07:49 |
| *** links has quit IRC | 07:54 | |
| *** Tiancheng has quit IRC | 08:08 | |
| *** Tiancheng_ has joined #openstack-lbaas | 08:08 | |
| *** _cjones_ has quit IRC | 08:15 | |
| openstackgerrit | Banashankar k proposed openstack/octavia: Need to change the length of name in the algorithm since we are updating the lenght of the lb_algorithm in pool table we need to change the name column in algorithm table as its a FK. https://review.openstack.org/271178 | 08:19 |
| *** idonotknow has quit IRC | 08:19 | |
| openstackgerrit | Banashankar k proposed openstack/octavia: Need to change the length of name in the algorithm since we are updating the lenght of the lb_algorithm in pool table we need to change the name column in algorithm table as its a FK. https://review.openstack.org/271178 | 08:21 |
| *** links has joined #openstack-lbaas | 08:22 | |
| rm_work | bana_k: need to fix your commit message title :P | 08:22 |
| *** numans has quit IRC | 08:32 | |
| *** jwarendt has joined #openstack-lbaas | 08:32 | |
| *** links has quit IRC | 08:35 | |
| *** jwarendt has quit IRC | 08:37 | |
| sbalukoff | bana_k: Good catch on that, eh. (D'oh! I should have caught that in my fix last week. :P ) | 08:41 |
| rm_work | weird that nothing exploded in my testing | 08:45 |
| rm_work | because i definitely tested your patch along with a few others in my devstack and it never broke... | 08:45 |
| rm_work | can you edit an existing migration like that? because ... i guess we need to? but it seems odd | 08:47 |
| *** idonotknow has joined #openstack-lbaas | 09:01 | |
| idonotknow | Hi,everyone.Does anyone know why my loadbalancer is always on PENDING_UPDATE when I restart a vm manually. lbaasv2 I found that it will change to ACTIVE when time expires.Anyone know why? | 09:02 |
| *** numans has joined #openstack-lbaas | 09:16 | |
| *** idonotknow has quit IRC | 09:46 | |
| *** bradjones_ has quit IRC | 10:28 | |
| *** bradjones_ has joined #openstack-lbaas | 10:29 | |
| *** bradjones_ has quit IRC | 10:29 | |
| *** bradjones_ has joined #openstack-lbaas | 10:29 | |
| *** bradjones_ has quit IRC | 10:40 | |
| *** bradjones_ has joined #openstack-lbaas | 10:41 | |
| *** bradjones_ has quit IRC | 10:41 | |
| *** bradjones_ has joined #openstack-lbaas | 10:41 | |
| *** bradjones_ has quit IRC | 10:45 | |
| *** bradjones_ has joined #openstack-lbaas | 10:47 | |
| *** bradjones_ has quit IRC | 10:47 | |
| *** bradjones_ has joined #openstack-lbaas | 10:47 | |
| *** Tiancheng_ has quit IRC | 11:19 | |
| *** yamamoto_ has quit IRC | 11:25 | |
| *** fnaval has joined #openstack-lbaas | 11:34 | |
| *** openstackgerrit has quit IRC | 11:47 | |
| *** openstackgerrit has joined #openstack-lbaas | 11:48 | |
| *** bradjones_ has quit IRC | 11:52 | |
| *** numans has quit IRC | 11:53 | |
| *** bradjones_ has joined #openstack-lbaas | 11:53 | |
| *** bradjones_ has quit IRC | 11:53 | |
| *** bradjones_ has joined #openstack-lbaas | 11:53 | |
| *** bradjones has quit IRC | 12:01 | |
| *** bradjones_ is now known as bradjones | 12:01 | |
| *** yamamoto has joined #openstack-lbaas | 12:09 | |
| *** yamamoto has quit IRC | 12:13 | |
| *** yamamoto has joined #openstack-lbaas | 12:15 | |
| *** rtheis has joined #openstack-lbaas | 12:24 | |
| *** yamamoto has quit IRC | 12:32 | |
| *** yamamoto has joined #openstack-lbaas | 12:32 | |
| *** yamamoto has quit IRC | 12:33 | |
| *** openstackgerrit has quit IRC | 12:33 | |
| *** yamamoto has joined #openstack-lbaas | 12:33 | |
| *** openstackgerrit has joined #openstack-lbaas | 12:34 | |
| *** yamamoto has quit IRC | 12:46 | |
| *** yamamoto has joined #openstack-lbaas | 12:46 | |
| *** numans has joined #openstack-lbaas | 12:49 | |
| *** yamamoto has quit IRC | 12:51 | |
| *** yamamoto has joined #openstack-lbaas | 13:14 | |
| *** ducttape_ has joined #openstack-lbaas | 13:30 | |
| *** bochi-michael has quit IRC | 13:34 | |
| *** diogogmt has quit IRC | 13:35 | |
| *** diogogmt has joined #openstack-lbaas | 13:36 | |
| *** ducttape_ has quit IRC | 13:43 | |
| *** diogogmt has quit IRC | 13:47 | |
| *** doug-fish has joined #openstack-lbaas | 13:55 | |
| *** sbalukoff1 has joined #openstack-lbaas | 14:00 | |
| *** sbalukoff has quit IRC | 14:04 | |
| *** neelashah has joined #openstack-lbaas | 14:10 | |
| *** pcaruana has joined #openstack-lbaas | 14:46 | |
| *** yamamoto has quit IRC | 14:52 | |
| *** ducttape_ has joined #openstack-lbaas | 15:09 | |
| *** diogogmt has joined #openstack-lbaas | 15:12 | |
| openstackgerrit | Jialiang proposed openstack/neutron-lbaas: Screen service q-lbaasv2 is not needed w/ octavia https://review.openstack.org/271365 | 15:13 |
| *** numans has quit IRC | 15:28 | |
| *** woodster_ has joined #openstack-lbaas | 15:44 | |
| *** kobis has joined #openstack-lbaas | 15:51 | |
| *** kobis has quit IRC | 15:54 | |
| *** TrevorV has joined #openstack-lbaas | 15:57 | |
| *** TrevorV has quit IRC | 15:59 | |
| *** TrevorV has joined #openstack-lbaas | 16:00 | |
| *** rtheis has quit IRC | 16:05 | |
| *** patient-0-bl0gan is now known as blogan | 16:05 | |
| *** rtheis has joined #openstack-lbaas | 16:05 | |
| blogan | ping sbalukoff1 | 16:05 |
| *** minwang2 has joined #openstack-lbaas | 16:06 | |
| *** rcernin has quit IRC | 16:15 | |
| *** armax has joined #openstack-lbaas | 16:33 | |
| *** TrevorV has quit IRC | 16:43 | |
| *** TrevorV has joined #openstack-lbaas | 16:44 | |
| xgerman | morning | 16:45 |
| blogan | morning | 16:45 |
| *** TrevorV has quit IRC | 16:46 | |
| *** kobis has joined #openstack-lbaas | 16:46 | |
| *** TrevorV has joined #openstack-lbaas | 16:47 | |
| *** TrevorV has quit IRC | 16:49 | |
| *** kobis has quit IRC | 16:50 | |
| *** TrevorV has joined #openstack-lbaas | 16:50 | |
| *** rcernin has joined #openstack-lbaas | 16:54 | |
| *** minwang2 has quit IRC | 16:55 | |
| *** TrevorV has quit IRC | 16:56 | |
| sbalukoff1 | Morning! | 17:01 |
| sbalukoff1 | What's up blogan? | 17:01 |
| *** sbalukoff1 is now known as sbalukoff | 17:01 | |
| rm_work | sbalukoff: you can have him in a moment, we're huddling :P | 17:03 |
| sbalukoff | Haha! | 17:03 |
| sbalukoff | I'm just responding since he pinged me about an hour ago. | 17:03 |
| *** crc32 has joined #openstack-lbaas | 17:07 | |
| *** _cjones_ has joined #openstack-lbaas | 17:13 | |
| *** _cjones_ has quit IRC | 17:14 | |
| *** _cjones_ has joined #openstack-lbaas | 17:14 | |
| a2hill | What's the triple0 channel? Anyone know? | 17:14 |
| sbalukoff | I have no idea, but I want to see that patch merged ASAP as well. XD | 17:16 |
| sbalukoff | But hey! At least I'm not dead in the water right now. | 17:17 |
| a2hill | indeed | 17:17 |
| a2hill | :P | 17:17 |
| a2hill | Think i pinged in the right channel, well see where this goes. | 17:21 |
| *** johnsom_ has joined #openstack-lbaas | 17:26 | |
| *** minwang2 has joined #openstack-lbaas | 17:30 | |
| *** ducttape_ has quit IRC | 17:31 | |
| *** ducttape_ has joined #openstack-lbaas | 17:32 | |
| *** ducttape_ has quit IRC | 17:33 | |
| *** ducttape_ has joined #openstack-lbaas | 17:34 | |
| *** ducttape_ has quit IRC | 17:34 | |
| *** ducttape_ has joined #openstack-lbaas | 17:35 | |
| *** jwarendt has joined #openstack-lbaas | 17:37 | |
| *** mdavidson has quit IRC | 17:50 | |
| *** crc32 has quit IRC | 17:59 | |
| *** armax has quit IRC | 18:25 | |
| *** fnaval has quit IRC | 18:26 | |
| *** bana_k has quit IRC | 18:28 | |
| *** TrevorV has joined #openstack-lbaas | 18:32 | |
| *** kobis has joined #openstack-lbaas | 18:35 | |
| kobis | blogan: while we discussed this, I think that you mentioned that you turn on other X-Forwarded-* headers | 18:37 |
| kobis | yet I can only see option forwardfor in the octavia templates | 18:38 |
| kobis | do I miss anything? | 18:38 |
| openstackgerrit | German Eichberger proposed openstack/octavia: Adds a parameter to specify endpoint type https://review.openstack.org/271476 | 18:44 |
| *** harlowja has quit IRC | 18:46 | |
| *** harlowja has joined #openstack-lbaas | 18:46 | |
| *** bana_k has joined #openstack-lbaas | 18:47 | |
| *** rcernin has quit IRC | 19:12 | |
| a2hill | kobis: At the moment there is only the XFF, things like XFP will be additional and is where having a 'generic' way to add these came up, so when the time does come we have a solidified way and not have to go t hrough this all again. | 19:49 |
| *** TrevorV has quit IRC | 19:55 | |
| rm_work | yeah, X-Forwarded-Port and X-Forwarded-Proto are used in our current infra | 20:00 |
| rm_work | in addition to X-Forwarded-For | 20:00 |
| rm_work | there's also apparently X-Forwarded-Host? but we don't use that | 20:00 |
| rm_work | looks like AWS provides just the first 3 | 20:00 |
| rm_work | https://tools.ietf.org/html/rfc7239#section-5 | 20:01 |
| rm_work | By, For, Host, Proto | 20:01 |
| rm_work | in that RFC | 20:01 |
| rm_work | I don't know what others :/ | 20:01 |
| a2hill | I'd be ok with atleast support that set of headers even if its less than 'generic' assuming they can all be toggled. We dont have to solve for everything, I just wanted to solve for the couple I knew for sure we were going to add | 20:07 |
| a2hill | supporting* | 20:07 |
| a2hill | It was more so the idea of being able to add those later without hassel, so if we add them all now, again, in a less 'generic' fashion im totally ok with it. | 20:08 |
| a2hill | cant type today :( | 20:09 |
| *** blogan_ has joined #openstack-lbaas | 20:09 | |
| blogan | sbalukoff: ping again | 20:10 |
| sbalukoff | What's up, eh? | 20:11 |
| blogan | hey was giong to rehash some things we talked about with the shared pool stuff, stuff i believe you've already told me but not sure if i remember correctly | 20:11 |
| a2hill | Im interested in anything about shared pools currently, can I listen in? | 20:12 |
| a2hill | :) | 20:12 |
| sbalukoff | blogan: Fire away! | 20:12 |
| sbalukoff | a2hill: Please! | 20:12 |
| blogan | sbalukoff: basically i still don't like the pool being directly tied to the LB in the API, i dont care if we do it in the db, but is there a reason we couldn't just have the user create a pool on a listener only? dont worry about L7 right now, we can get to that | 20:13 |
| sbalukoff | (I'm actually working on that stuff now-- was able to reproduce the bug that a2hill found; Have a fix for that, but discovered another bug in the process. Yay!) | 20:13 |
| a2hill | awesome! :) | 20:13 |
| blogan | whack a bug mole | 20:13 |
| johnsom_ | Yeah, I'm planning to hit that review on the train back today | 20:13 |
| a2hill | If we do what blogan is suggesting this is even less user impactful right? | 20:14 |
| sbalukoff | blogan: Use case: I want to create a L7 policy that routes to another pool. In order to do this, that pool must exist. But that pool is not the default_pool of any listener. | 20:14 |
| sbalukoff | Therefore, I need to be able to create that pool outside of the context of a listener. | 20:14 |
| blogan | sbalukoff: but you can in the context of an L7 policy no? | 20:14 |
| *** pcaruana has quit IRC | 20:14 | |
| sbalukoff | Since all the legacy URLs assume that in the context of the listener, it's the default pool. | 20:14 |
| a2hill | That makes sense also | 20:14 |
| sbalukoff | A pool should not be the daughter of an L7policy. | 20:15 |
| blogan | so how do you point the L7 policy to the pool? | 20:15 |
| sbalukoff | blogan: Can you give me a good technical reason we should only access pools in the context of a listener? | 20:15 |
| openstackgerrit | Trevor Vardeman proposed openstack/octavia: Amphora create will add a 'fake' heartbeat on creation. https://review.openstack.org/271512 | 20:15 |
| *** TrevorV has joined #openstack-lbaas | 20:16 | |
| sbalukoff | Workflow is: create listener (with or without default pool) -> create pool -> create l7policy that references the pool (l7policies exist in the context of a listener) | 20:16 |
| blogan | sbalukoff: no technical reason, just consistency with the API and look and feel | 20:17 |
| a2hill | Yea, that's the only thing I could think of too | 20:17 |
| sbalukoff | blogan: The legacy API should still work as before. | 20:18 |
| blogan | so why couldnt the workflow be: create listener (with or without default pool) -> create l7policy -> create pool that associates with a particular l7 policy | 20:18 |
| sbalukoff | blogan: It could. But there's no reason for this. That same pool might be a default pool elsewhere, or get referenced by several listeners. | 20:19 |
| sbalukoff | Keeping those old URLs is actually a crutch. | 20:19 |
| sbalukoff | You need to get over the fact that a pool is a peer with a listener, not a child. :) | 20:19 |
| blogan | yeah it could and it would then at that point be easy to associate a listener with that pool now, just wiht the uuid | 20:19 |
| blogan | i cant! | 20:19 |
| sbalukoff | The old URLs also make things more complicated. | 20:19 |
| blogan | what do you mean old urls? | 20:20 |
| sbalukoff | It's actually simpler the way I'm recommending! | 20:20 |
| a2hill | hard mode activated | 20:20 |
| blogan | simpler to implement or simpler for an api user to understand? | 20:20 |
| sbalukoff | Old style-- introducing what feels like a parent -> child relationship even though that's not really what it is. | 20:20 |
| sbalukoff | Er... | 20:20 |
| sbalukoff | I would actually say that faking that relationship can lead to confusion. | 20:21 |
| blogan | well actually we had them all originally able to be created independently, but the whole driver being determined by the LB made that complicated | 20:21 |
| sbalukoff | Suppose I have a pool that's a default_pool for listener1 and referenced by an l7policy in listener2. If I change it in the context of listener1, this will also change it in the context of that l7policy in listener2. This is confusing to the end-user. | 20:21 |
| sbalukoff | Better not fake it. | 20:22 |
| sbalukoff | Better change the pool in the context of the loadbalancer (where it really lives), and it's clearer this will affect all such references. | 20:22 |
| blogan | how would they change it in the context of either one of those? they'd be changing it by updating /pools/{pool_id} | 20:22 |
| sbalukoff | ... | 20:22 |
| sbalukoff | Ok, now you're confusing me. | 20:22 |
| blogan | lol | 20:22 |
| blogan | i'm probably confused | 20:23 |
| blogan | i'm going with neutron lbaas btw | 20:23 |
| blogan | not octavia | 20:23 |
| sbalukoff | I thought you were saying you wanted to reference things using a URL that looks like: /loadbalancers/UUID/listeners/UUID/l7policies/UUID/pools/UUID | 20:23 |
| sbalukoff | Instead of just /loadbalancers/UUID/pools/UUID | 20:23 |
| *** TrevorV has quit IRC | 20:23 | |
| blogan | oh yeah this would have ramifications to that too | 20:23 |
| sbalukoff | Well... things are already not nested in neutron lbaas. | 20:23 |
| sbalukoff | So, I'm confused at what you're asking, now. | 20:24 |
| blogan | yes but a user still will specify loadbalancer_id in neutron lbaas no? | 20:24 |
| blogan | on a pool create | 20:24 |
| blogan | they have that option | 20:24 |
| sbalukoff | They can specify either loadbalancer_id or listener_id. | 20:24 |
| *** crc32 has joined #openstack-lbaas | 20:24 | |
| sbalukoff | The API "does the right thing" and looks up the loadbalancer_id if the listener_id is specified. | 20:25 |
| sbalukoff | So the API knows that when the user says "create this pool on this listener" what they really mean is "create this pool on this loadbalancer and associate it with this listener" | 20:25 |
| *** TrevorV has joined #openstack-lbaas | 20:26 | |
| *** johnsom_ has quit IRC | 20:26 | |
| blogan | it really is i just can't put listeners and pools as peers | 20:26 |
| sbalukoff | Why? | 20:26 |
| sbalukoff | Seriously, I feel like we're only having this discussion because it feels icky to you. | 20:27 |
| blogan | bc a pool needs a listener to be useful (even through L7) | 20:27 |
| sbalukoff | Right. And a listener in 99.99% of the time is useless without a pool. | 20:27 |
| blogan | so do you agree that load balancer is the parent to a listener? | 20:28 |
| sbalukoff | The way we have things modeled right now, yes. | 20:28 |
| blogan | well in whatever way you see it | 20:29 |
| sbalukoff | Eventually-- when we do true IPv6 support, a listener may end up being another entity that gets shared across loadbalancers, and then it'll exist independently of the loadbalancer. (And the pool will have to be altered this way in parallel.) | 20:29 |
| sbalukoff | But that's a can of worms we don't need to open right now... | 20:29 |
| sbalukoff | because nobody is asking for it vere loudly yet. | 20:30 |
| rm_work | oh man, just reading over this | 20:30 |
| rm_work | is that really what our endpoints look like? | 20:30 |
| blogan | i agree thats going to be the best way to solve for multiple ips | 20:30 |
| rm_work | "/loadbalancers/UUID/listeners/UUID/l7policies/UUID/pools/UUID" | 20:30 |
| rm_work | cause, gross | 20:30 |
| a2hill | no | 20:30 |
| rm_work | i didn't think it was | 20:30 |
| a2hill | :P | 20:30 |
| blogan | that one url i agree doesn't seem right | 20:31 |
| rm_work | I thought /loadbalancers/UUID/pools/UUID would be what we'd use | 20:31 |
| sbalukoff | blogan: yep! But again, not a feature high in demand right now. | 20:31 |
| blogan | damnit rm_work | 20:31 |
| rm_work | lol | 20:31 |
| a2hill | Playing with the API the bit that I have it doesnt feel icky honestly. The logic makes sense, though, because of the additional features(l7) it feels like it would make things a little more difficult, but im on the side of the fence that if its documented properly and not overly convoluted it seems like the right way | 20:31 |
| sbalukoff | rm_work: That's what we will use on Octavia. | 20:31 |
| sbalukoff | Once my shared pools patch lands. | 20:31 |
| sbalukoff | (Though, again, the old URLs will also work, even though they're deprecated.) | 20:31 |
| rm_work | well | 20:32 |
| rm_work | can a pool be shared ACROSS LBs too/ | 20:32 |
| rm_work | ? | 20:32 |
| blogan | no | 20:32 |
| blogan | not right now | 20:32 |
| rm_work | hmm | 20:32 |
| blogan | thats what we just got done talking about, its a big pain in the ass we're nto ready to unleash | 20:32 |
| sbalukoff | Right. | 20:32 |
| rm_work | sorry to cause a rehash | 20:33 |
| sbalukoff | It'll be a more difficult transition that this shared pools patch is because it'll affect both pools and listeners hierarchies at the same time. | 20:33 |
| sbalukoff | s/that this/than this/ | 20:33 |
| rm_work | well | 20:33 |
| rm_work | if a LB can have multiple listeners (it can) and each listener can have a different pool (they can) then I think actually blogan makes sense here | 20:34 |
| rm_work | "/loadbalancers/UUID/pools/UUID" doesn't seem sensical for that | 20:34 |
| rm_work | because that isn't where the association truly is | 20:34 |
| sbalukoff | rm_work: The whole point of my patch is that listeners can share pools. | 20:34 |
| rm_work | they CAN | 20:34 |
| rm_work | but they won't always | 20:34 |
| sbalukoff | And yes, dammit, it is where the association is truly. | 20:35 |
| blogan | btw i'm not a strongly against it, its just one of those pesky things that perhaps I need to talk with someboday to get through to acceptance, or maybe its something thats valid | 20:36 |
| rm_work | https://gist.github.com/rm-you/d3c53de66a85e725d878 | 20:37 |
| rm_work | the first is what I see | 20:37 |
| rm_work | the second is what you're saying? I think? | 20:37 |
| rm_work | where they are just tagged with what listener they are used by? | 20:37 |
| rm_work | I'm not even 100% sure how that'd work | 20:37 |
| blogan | you're confusing | 20:37 |
| rm_work | I guess they'd have a list of listeners? | 20:38 |
| blogan | listeners and pools would be on the same level | 20:38 |
| sbalukoff | ... | 20:38 |
| sbalukoff | No. | 20:38 |
| sbalukoff | Well, yes, but not the way you think. | 20:38 |
| blogan | /loadbalancers/{lb_id}/listeners | 20:38 |
| rm_work | yes | 20:38 |
| blogan | /loadbalancers/{lb_id}/pools | 20:38 |
| rm_work | but how do you show which listener a pool is associated with | 20:38 |
| rm_work | i guess no back-linking? | 20:38 |
| sbalukoff | A listener has a list of pools. And a pool has a list of listeners-- but that's not "in the model" as it were-- that's only for convenience when you're writing code that has to iterate through them. | 20:38 |
| sbalukoff | listeners have a default pool. | 20:39 |
| rm_work | yeah sorry didn't mean to *leave out* listeners there | 20:39 |
| sbalukoff | But otherwise, listeners and pools can have a relationship through an l7policy. | 20:39 |
| rm_work | updated gist | 20:39 |
| *** crc32 has quit IRC | 20:39 | |
| rm_work | if we don't care about back-refs explicitly, maybe the second way is cleaner | 20:40 |
| rm_work | err sorry | 20:41 |
| sbalukoff | back-refs? As in, SQLAlchemy back-refs? | 20:41 |
| rm_work | if we *do provide* back-refs explicitly | 20:41 |
| rm_work | the concept | 20:41 |
| rm_work | like, the pool object has refs to listeners using it | 20:41 |
| sbalukoff | Right... | 20:41 |
| rm_work | in its return | 20:41 |
| blogan | backrefs were through the url basically, but obviously the url can't show many | 20:41 |
| rm_work | yeah | 20:41 |
| sbalukoff | If you look at the code I've actually written on this (especially the L7 schema code) you can see how I build that list. | 20:42 |
| rm_work | k, i'll go review that now | 20:42 |
| *** crc32 has joined #openstack-lbaas | 20:43 | |
| blogan | sbalukoff: i think rm_work is saying he woudl like backrefs from pools to listeners to be there, which i dont think they are in octavia, which really isn't a big deal right now | 20:43 |
| sbalukoff | I imagine the shared pools thing seems like a lot of work for little gain... unless you're thinking about how this stuff will have to work when l7policies are introduced. | 20:43 |
| blogan | meh i don't think its for little gain, we all know we need it | 20:43 |
| sbalukoff | blogan: The L7policy stuff adds them to the model. We could make the API also list them if you want. | 20:43 |
| rm_work | ok so looking at the model, i still don't really understand | 20:44 |
| blogan | i mean we could just make the user recreate the same pool over and over | 20:44 |
| blogan | but thats a bad experience | 20:44 |
| sbalukoff | Very bad.. | 20:44 |
| rm_work | the model for the pool has a direct link to an LB, but your property for the listener_id says it has no such relationship?! | 20:44 |
| sbalukoff | Especially when you consider that the way l7rules work, there is no 'or' statement. | 20:44 |
| rm_work | I thought it was explicitly a pool->listener relationship, and the pool->LB relationship was only implied through the listener | 20:44 |
| sbalukoff | So in order to fake it you have to create multiple l7policies, each of which reference a pool, every time you'd otherwise use an 'or' | 20:45 |
| rm_work | https://review.openstack.org/#/c/218560/17/neutron_lbaas/db/loadbalancer/models.py line 211 | 20:45 |
| rm_work | either this is wonky or I don't actually know how our API works *at all* | 20:45 |
| blogan | thats db not api | 20:45 |
| rm_work | I thought a *listener* had a pool defined | 20:45 |
| rm_work | why would the DB representation be significantly different here? | 20:45 |
| blogan | for the db models it has default_pool | 20:46 |
| sbalukoff | listener has a default_pool_id | 20:46 |
| rm_work | right, listeners have pools | 20:46 |
| sbalukoff | It's *not* significantly different. | 20:46 |
| rm_work | LBs don't have pools | 20:46 |
| sbalukoff | No, *A* listener has *one* default_pool. | 20:46 |
| rm_work | but PoolV2 has a direct link to an LB_ID and none to a Listener | 20:46 |
| blogan | PoolV2 gives it to it through SA's backref | 20:46 |
| rm_work | SA? | 20:47 |
| a2hill | sqlalchemy | 20:47 |
| rm_work | ah | 20:47 |
| rm_work | on the listener side? | 20:47 |
| rm_work | so it's just not visible here | 20:48 |
| rm_work | why would the listener_id property be a dummy like this then? | 20:48 |
| rm_work | why wouldn't it return proper data (list of referencing listeners) | 20:48 |
| sbalukoff | Because some drivers and whatnot expect to see it. :P | 20:48 |
| rm_work | but you have it returning None, not ... the actual data | 20:48 |
| rm_work | and have a note saying the relationship doesn't exist / is fake | 20:49 |
| sbalukoff | Because the 'actual data' is None? | 20:49 |
| *** fnaval has joined #openstack-lbaas | 20:49 | |
| rm_work | when it's more direct than the pool->LB relationship? | 20:49 |
| rm_work | err | 20:49 |
| sbalukoff | pools don't have a 'listener' | 20:50 |
| rm_work | listeners are parent objects of pools -- a pool should have between 0 and N listener parents, but if it doesn't have at least 1 listener parent, it can't possibly have an LB parent either? | 20:50 |
| sbalukoff | They have a list of listeners. | 20:50 |
| sbalukoff | And this list might be empty | 20:50 |
| rm_work | right, a list | 20:50 |
| rm_work | 0 to N | 20:50 |
| blogan | rm_work has the same trouble i am | 20:50 |
| rm_work | but if the list is empty, there IS NO LB | 20:51 |
| rm_work | because the relationship from Pool->LB is traced through listeners | 20:51 |
| rm_work | Pool->Listener->LB | 20:51 |
| sbalukoff | No, it's not! | 20:51 |
| rm_work | ??? | 20:51 |
| rm_work | how does a pool have a relationship to an LB without a listener | 20:51 |
| rm_work | blogan am I insane? | 20:51 |
| sbalukoff | You're looking at the code. | 20:51 |
| sbalukoff | It's got a reference right there. | 20:51 |
| blogan | rm_work: i'm having the same problem letting go of that hierarchy too | 20:52 |
| rm_work | i'm saying this CODE doesn't make sense | 20:52 |
| sbalukoff | pool.loadbalancer is a thing. | 20:52 |
| rm_work | yes | 20:52 |
| rm_work | but HOW | 20:52 |
| rm_work | how can that field possibly be filled | 20:52 |
| rm_work | you can't just add a pool to an LB | 20:52 |
| sbalukoff | Are you just messing with me right now? | 20:52 |
| blogan | code filled it? | 20:52 |
| sbalukoff | Yes, in fact, you can. | 20:52 |
| rm_work | ... how | 20:52 |
| rm_work | what is the relationship | 20:52 |
| blogan | rm_work: are you asking how its technically done in code or logically how a pool's direct parent is load balancer? | 20:52 |
| sbalukoff | A pool, in this model, is a child of a loadbalancer. | 20:53 |
| a2hill | rm_work: maybe this is things that could be put into the review, or maybe needs some sit down time to understand? | 20:53 |
| rm_work | the LB object doesn't have pools though | 20:53 |
| rm_work | listeners have pools | 20:53 |
| sbalukoff | Yes, it does! | 20:53 |
| *** fnaval has quit IRC | 20:53 | |
| rm_work | >_> | 20:53 |
| a2hill | we have a ticket for it, ive been doing that since lastnight really | 20:53 |
| blogan | yes it does | 20:53 |
| rm_work | are you messing with ME right now? | 20:53 |
| blogan | PoolV2 puts it on LoadBlanacer | 20:53 |
| rm_work | what does a LB having a pool mean | 20:53 |
| rm_work | it seems meaningless to me | 20:53 |
| rm_work | I could give a VIP a pool too | 20:53 |
| sbalukoff | Let me see if I can make an analogy.. | 20:53 |
| rm_work | <_< | 20:53 |
| sbalukoff | In order to have a functional "driving service" you need to have a complete car that includes both wheels and a motor. | 20:54 |
| sbalukoff | In some, very rare circumstances, you can get away without a motor. (This would be like a listener without a pool.) | 20:54 |
| sbalukoff | But most people want to do more than roll downhill.. | 20:54 |
| sbalukoff | So you also need a motor in most cases. | 20:55 |
| blogan | can you ever have a pool without a listener though? | 20:55 |
| blogan | not in ths model! | 20:55 |
| blogan | logicaly speaking | 20:55 |
| sbalukoff | yes! And yes, my analogy isn't that great. | 20:55 |
| rm_work | if you had a pool and no listener, nothing would ever happen | 20:55 |
| blogan | is a pool useful without a listener? | 20:55 |
| rm_work | and even if you add a pool to a LB | 20:55 |
| sbalukoff | It will be useless-- much like a listener without a pool is useless. | 20:55 |
| rm_work | what does that MEAN | 20:55 |
| sbalukoff | To be useful you need both. | 20:55 |
| blogan | and a load balancer by itself is useless | 20:55 |
| sbalukoff | Yep. | 20:56 |
| blogan | but we allow that | 20:56 |
| rm_work | if you create an LB, and add a pool to it... then add two listeners... you still have to tell the listeners to use the pool, np? | 20:56 |
| rm_work | *no? | 20:56 |
| blogan | and since all these things are useless without each other, htey should all have just been one big ass object | 20:56 |
| sbalukoff | rm_work. Yep, and you can do so by specifying the 'default_pool_id' in the code I've written. | 20:56 |
| rm_work | err | 20:56 |
| sbalukoff | So yes. you can vary the order in which you create things. | 20:56 |
| a2hill | blogan +1 :P | 20:56 |
| sbalukoff | lb -> pool -> listener is a valid workflow. | 20:56 |
| rm_work | so I create an LB object. then I create a pool and link it to the LB.... then I create two listeners... | 20:56 |
| rm_work | both listeners automatically use that pool? | 20:56 |
| sbalukoff | blogan: -1 | 20:57 |
| a2hill | >< | 20:57 |
| blogan | lol | 20:57 |
| sbalukoff | blogan: Are you trying to go back to the bad ol' days of LBaaSv1? | 20:57 |
| sbalukoff | (Was that actually a joke?) | 20:57 |
| rm_work | sbalukoff: can you answer my more clearly defined question? :P | 20:57 |
| blogan | ha no i just think this would be easier with only being able to create a load balancer with the full tree | 20:58 |
| sbalukoff | rm_work: If you create a listener and specify the default-pool-id of an already existent pool, then yes, that listener will use that pool as its default pool. | 20:58 |
| rm_work | nonono | 20:58 |
| rm_work | I create a *loadbalancer* | 20:58 |
| a2hill | rm_work: no it wont | 20:58 |
| rm_work | set a pool on it | 20:58 |
| a2hill | You have to associate | 20:58 |
| rm_work | and then create two listeners on the LB | 20:58 |
| rm_work | what happens | 20:58 |
| a2hill | it just puts listeners on the lb object | 20:58 |
| rm_work | if the answer is "nothing", then what the hell is the point of specifying a pool on the loadbalancer | 20:59 |
| rm_work | you have to specify it on the *listener* | 20:59 |
| sbalukoff | If you don't specify the default_pool_id, then the new listeners won't automatically use the pool that's on the load balancer. You actually do have to specify the default_pool id. | 20:59 |
| rm_work | rofl | 20:59 |
| rm_work | sbalukoff: I feel like you're trolling me | 20:59 |
| sbalukoff | Like... you know... you have to plug in your computer. It's not enough to put it near the outlet. | 20:59 |
| rm_work | so we have a pool linked to a loadbalancer. this link does *absolutely nothing* | 20:59 |
| sbalukoff | rm_work: I'm really trying not to. I have a hard time believing these concepts are that difficult. :P | 20:59 |
| rm_work | ....... | 21:00 |
| rm_work | ok so | 21:00 |
| rm_work | tell me true or false: | 21:00 |
| sbalukoff | the link from loadbalancer -> pool limits scope. | 21:00 |
| rm_work | linking the pool to the loadbalancer has absolutely zero functional use | 21:01 |
| rm_work | true or false | 21:01 |
| rm_work | ... why would we bother with that? what does that buy us? | 21:01 |
| rm_work | link the listener->pool | 21:01 |
| rm_work | and we get ... a working thing | 21:01 |
| sbalukoff | the link from loadbalancer to pool limits scope-- you know that if you alter that pool it will at most affect things on that single load balancer. | 21:01 |
| sbalukoff | No we don't. | 21:02 |
| rm_work | lb->listener->pool chain | 21:02 |
| rm_work | and we do, yes | 21:02 |
| sbalukoff | Right, so car needs an engine to be useful. | 21:02 |
| rm_work | yeah but the wheels are attached to the driveshaft which is attached to the engine | 21:03 |
| sbalukoff | Yeah, my analogy isn't that great. | 21:03 |
| rm_work | unfortunately in that analogy the wheels are also attached to the car for physics purposes | 21:03 |
| rm_work | but in a virtual world they wouldn't have to be :P | 21:03 |
| rm_work | so it'd be car->engine->wheels | 21:03 |
| sbalukoff | I'm not following yo. | 21:03 |
| sbalukoff | you. | 21:03 |
| rm_work | frame->engine->wheels | 21:04 |
| rm_work | is like | 21:04 |
| rm_work | lb->listener->pool? | 21:04 |
| rm_work | seems to be your analogy | 21:04 |
| blogan | btw got a short meeting i gotta focus on, ill be back shortly | 21:04 |
| rm_work | or rather | 21:04 |
| rm_work | frame/engine/wheels | 21:04 |
| a2hill | i see pool as the engine, thats what ends up making the haproxy do useful things | 21:04 |
| rm_work | because you are saying there's no hierarchy | 21:04 |
| rm_work | but there is | 21:04 |
| a2hill | wheels by themselves do nothing, and is where his anology sits with me | 21:05 |
| rm_work | let me show you a car with no frame :P | 21:05 |
| sbalukoff | Right. You need all the pieces for a complete service. | 21:05 |
| rm_work | http://www.miataturbo.net/attachment.php?attachmentid=33600&dateline=1328588543 | 21:05 |
| rm_work | engine -> wheels | 21:05 |
| rm_work | :P | 21:06 |
| sbalukoff | So... let's pretend I'm not using haproxy right now. | 21:06 |
| a2hill | There's definately some difference in thought processes here, Im kind of on the fence here. Because I totally agree that it feels like the wrong relationships as it stands, but using it made sense | 21:07 |
| sbalukoff | On some other load balancers you can create a pool... and the load balancer will do health checks on the members and return status information, etc... | 21:08 |
| rm_work | to me it is pretty clear that the hierarchy is LB->Listener->Pool | 21:08 |
| rm_work | hmm | 21:08 |
| rm_work | so what are we talking about right now | 21:08 |
| rm_work | N-LBaaS or Octavia? | 21:08 |
| rm_work | I guess this matters | 21:08 |
| sbalukoff | And it might be useful in some cases for those load balancer (using models more complicated than we allow right now) to make, say, a routing decision based on the health of a pool. | 21:08 |
| sbalukoff | Both, technically. | 21:08 |
| rm_work | for octavia I can't think of a valid reason to have a Pool on a LB directly | 21:09 |
| rm_work | because we don't do those things | 21:09 |
| rm_work | but if some WILL start health checks before a listener exists... | 21:09 |
| rm_work | then that's worth looking into | 21:09 |
| sbalukoff | How about: Because it makes things a fuckton easier when you do L7?) | 21:09 |
| a2hill | that is supposed to be the context this is reviewed in | 21:09 |
| rm_work | can you create a pool without linking it to something? | 21:10 |
| xgerman | well, something crazy | 21:10 |
| rm_work | i guess maybe that isn't possible anymore? | 21:10 |
| sbalukoff | Yep. I agree that without L7, shared pools is probably more trouble than it's worth. | 21:10 |
| xgerman | can’t we make the relationship pool -> listener a resource? | 21:10 |
| sbalukoff | rm_work: It wasn't possible originally. | 21:10 |
| rm_work | it was in V1 | 21:10 |
| rm_work | that's what I meant by "anymore" | 21:10 |
| * xgerman still catching up | 21:10 | |
| *** fnaval has joined #openstack-lbaas | 21:10 | |
| sbalukoff | v1 concept of "pool" is incompatible here. | 21:11 |
| rm_work | true, but IIRC you could create objects without linking them up | 21:11 |
| rm_work | and I guess now you can't? | 21:11 |
| xgerman | so we do loadbalancer/123/pool/123 | 21:11 |
| rm_work | so I think i see the problem you're trying to solve | 21:11 |
| sbalukoff | in v2 as it currently stands you can't. | 21:11 |
| a2hill | woah, we cant be comparing v1 to v2 here :P | 21:11 |
| sbalukoff | xgerman: With the shared pools patch, yes. | 21:11 |
| rm_work | I was imagining a workflow where you create a LB, then a Listener, then a pool, then link the pool to the listener by creating an L7Rule | 21:11 |
| sbalukoff | xgerman: But the old URLs will still work, for convenience's sake. | 21:12 |
| rm_work | but you can't have created the pool yet without linking it somewhere | 21:12 |
| xgerman | ok | 21:12 |
| * blogan starts reading scrollback | 21:12 | |
| * blogan understands he is the dr frankenstein of this | 21:12 | |
| rm_work | so that's the problem, right? | 21:12 |
| xgerman | so and then I do loadbalancer/123/listener/123 and post a list of pools among other things | 21:12 |
| sbalukoff | rm_work: And when you follow that train of thought... you discover that a pool and a listener are a lot alike as far as 'hierarchy' is concerned. I would say they're siblings. | 21:12 |
| rm_work | well, they link up | 21:13 |
| rm_work | they're still hierarchical | 21:13 |
| sbalukoff | rm_work: Yes, a car without wheels and a car without an engine are almost identically useless. | 21:13 |
| rm_work | eh | 21:13 |
| rm_work | yes | 21:14 |
| rm_work | but they still connect in a specific order | 21:14 |
| sbalukoff | ... | 21:14 |
| rm_work | http://www.onallcylinders.com/wp-content/uploads/2015/02/tboltEP2_07.jpg | 21:14 |
| a2hill | unless the car also has wings and rocket engines, then thats all invalid | 21:14 |
| xgerman | a car is a composition | 21:14 |
| sbalukoff | Only if you're thinking about things as far as "how is my request routed" | 21:14 |
| a2hill | sorry, ill stay out of it | 21:14 |
| sbalukoff | xgerman: Yes! | 21:14 |
| xgerman | and in REST we can do that by posting pool:{pool-id} | 21:15 |
| xgerman | on the listener | 21:15 |
| sbalukoff | xgerman: default-pool-id, but yes. | 21:15 |
| xgerman | so none of those crazy urls... | 21:15 |
| blogan | almost caught up, but i have to rejoin this meeting | 21:15 |
| sbalukoff | xgerman: When l7policies are introduced, these are logical children of listeners, and they can specify a 'redirect-pool-id' much the same wya. | 21:16 |
| sbalukoff | way. | 21:16 |
| xgerman | yep | 21:16 |
| xgerman | makes sense | 21:16 |
| sbalukoff | What I really, really want to avoid... | 21:16 |
| xgerman | loadbalancer/123/listener/123/l7/123 | 21:16 |
| sbalukoff | Is giving the API user the mistaken impression that altering /loadbalancers/UUID/listeners/UUID/pools/UUID is *not* going to also affect some other listener's pool. | 21:17 |
| sbalukoff | If that makes any sense. | 21:17 |
| *** fnaval_ has joined #openstack-lbaas | 21:17 | |
| sbalukoff | Again , the deprecated URL *will* work, but we want to encourage people to think about pools having some independence from listeners-- and that altering a pool might affect many listeners. | 21:18 |
| rm_work | http://asciiflow.com/#0B1uOZZC7pAeuS1F3ZUhIUU40cms | 21:19 |
| rm_work | isn't that the hierarchy (simplified)? | 21:19 |
| sbalukoff | That link isn't drawing anything for me. | 21:20 |
| rm_work | hmm | 21:20 |
| *** fnaval has quit IRC | 21:20 | |
| sbalukoff | Do you have to hit a 'save' button or something? | 21:20 |
| rm_work | not sure | 21:21 |
| rm_work | it says saved | 21:21 |
| sbalukoff | Well, it ain't showing me anything. :/ | 21:21 |
| rm_work | http://pastebin.com/uFRK1XA3 | 21:21 |
| rm_work | try that | 21:21 |
| rm_work | drawn in ~20 seconds | 21:21 |
| rm_work | so the real problem is that the pool on the bottom right *can't exist* | 21:22 |
| rm_work | right? | 21:22 |
| rm_work | because it isn't linked to anything | 21:22 |
| rm_work | (before creation of the L7) | 21:22 |
| sbalukoff | That's part of it, yes. The other part is that it's extremely common to want to re-use pools (ie. "shared pools") among many listeners and l7policies. | 21:22 |
| rm_work | yeah, so once the pool exists, you can do that no problem | 21:23 |
| rm_work | no need to have the pool specified on the LB :/ | 21:23 |
| rm_work | you could re-use the bottom-left pool on another listener too | 21:23 |
| sbalukoff | Ok, so we can't share pools between listeners? | 21:23 |
| xgerman | that picture makes it looks like pools are listener soecific | 21:23 |
| rm_work | sec | 21:23 |
| sbalukoff | What is the pool's parent in your mind? | 21:24 |
| rm_work | http://pastebin.com/83j61Cb2 | 21:24 |
| sbalukoff | What is the pool's parent? | 21:25 |
| rm_work | so first of all, IRL people have two parents each usually :P | 21:25 |
| rm_work | just like to point that out | 21:25 |
| rm_work | parent doesn't mean "one" | 21:25 |
| sbalukoff | Oh? | 21:25 |
| rm_work | in this case the pool's parents are two listeners and an L7Rule | 21:25 |
| sbalukoff | The pool has to exist somewhere, right? So where does it exist? | 21:25 |
| rm_work | yeah, so that's what I was trying to get from you -- is that the real problem? | 21:26 |
| rm_work | IIRC it'd be better to just make pool not require a linkage | 21:26 |
| sbalukoff | What linkage? | 21:26 |
| rm_work | than to force some fake relationship to an LB that does nothing | 21:26 |
| sbalukoff | the LB -> pool linkage limits scope in *exactly* the same ways as the LB -> listener linkage. | 21:27 |
| sbalukoff | For all the same reasons. | 21:27 |
| rm_work | the *only* think I see it doing functionally is "allowing somewhere to create a pool" since you can't create a pool by itself | 21:27 |
| rm_work | *only thing | 21:28 |
| rm_work | otherwise it serves no real functional purpose | 21:28 |
| sbalukoff | Do you understand what I mean when I say "limit scope"? | 21:28 |
| rm_work | because you'll *have to* link the pool to a listener either directly or via an L7Rule | 21:28 |
| rm_work | which does the scope limiting for you | 21:28 |
| rm_work | so the LB->pool link is redundant | 21:28 |
| rm_work | by the time it is able to be used at all | 21:28 |
| rm_work | you'll get the same scope limiting "feature" by linking the pool to a listener or an L7rule | 21:29 |
| sbalukoff | how would linking a pool to a given listener limit scope. | 21:29 |
| sbalukoff | Could I link the same pool to listeners on different loadbalancers? | 21:30 |
| blogan | ok im caught up mostly | 21:30 |
| blogan | linking a pool to a given listener means that pool can only be on that listener's load balancer | 21:30 |
| blogan | i mean thats how you'd do that | 21:30 |
| rm_work | sbalukoff: if we allowed that, then yes; but we don't? | 21:31 |
| rm_work | so by linking the pool to a listener, it has an implicit link to a LB | 21:31 |
| sbalukoff | rm_work: We don't allow listeners to be shared across loadbalancers right now. | 21:31 |
| rm_work | which gives it exactly the same scope limitations as linking it explicitly | 21:31 |
| rm_work | my point is that it works either way | 21:31 |
| sbalukoff | Right... so you're going to force me to traverse all the relationships of a given pool in order to discover whether it's actually linked / referenced by any listener or l7policy somewhere, right? | 21:32 |
| rm_work | no | 21:32 |
| rm_work | this is what i meant about back-refs on the pools earlier | 21:32 |
| blogan | rm_work: but the counter to that is then you'd need the /loadbalancers/{lb_id}/listeners/{listener_id}/l7polices/{l7policy_id}/pools endpoint to create a pool on an L7 policy bc you can't assume a pool is already the default pool of a listener | 21:32 |
| rm_work | i'd expext the pool object to have a list of all references | 21:32 |
| rm_work | because we can build that easily from the DB data | 21:33 |
| rm_work | blogan: right, i'm saying that if the problem is that you need to create a pool somewhere first | 21:33 |
| rm_work | i'd rather decouple it altogether | 21:33 |
| sbalukoff | rm_work: Yes, but then you have to look at all those references to find out which loadbalancer they're on. | 21:33 |
| sbalukoff | Why not cut out the middle man? | 21:33 |
| rm_work | sbalukoff: well, since you can't share pools across LBs, right now you can assume it's always on the same LB | 21:33 |
| sbalukoff | decoupling altogether is not something we wanted to do in this patch because it's a MUCH larger can of worms. | 21:34 |
| rm_work | sbalukoff: and if we allowed sharing pools across LBs, we wouldn't *want* to enforce that scope limitation | 21:34 |
| sbalukoff | rm_work: Yes! Of course! | 21:34 |
| blogan | rm_work: in your scenario how would you create a pool and associate it with an l7 policy? | 21:34 |
| xgerman | but we don’t want to share among lbs | 21:34 |
| sbalukoff | rm_work: But we don't want to allow sharing pools across LBs right now. | 21:34 |
| rm_work | blogan: create pool; create L7 policy with a pool_id | 21:34 |
| xgerman | sbalukoff +1 | 21:34 |
| rm_work | sbalukoff: right, not saying we should yet, but that it works either way | 21:35 |
| blogan | so create pool on a /pools endpoint? | 21:35 |
| blogan | a root /pools? | 21:35 |
| rm_work | blogan: yes | 21:35 |
| sbalukoff | ... | 21:35 |
| a2hill | :) | 21:35 |
| blogan | that runs into the problem of driver on the load balancer issue | 21:35 |
| sbalukoff | And that pool's parent would be? | 21:35 |
| rm_work | i'd rather explicitly decouple than create a fake/useless linkage to an LB object | 21:35 |
| rm_work | sbalukoff: it would be an orphan until it was given a parent listener via an L7Rule or the creation of a Listener specifying it | 21:35 |
| rm_work | ie, adopted | 21:36 |
| sbalukoff | rm_work: translation: I'd rather screw over any vendors who need pools creation events to happen independently of listener creation events. ;) | 21:36 |
| blogan | rm_work: i agree that would be ideal BUT we only know what the driver that pool should be sent to by the load balancer it is attached to | 21:36 |
| rm_work | sbalukoff: no, pool creation event in that case could happen absolutely independently of anything else? | 21:36 |
| xgerman | yeah, limiting scope is not useless | 21:36 |
| rm_work | xgerman: scope limitation happens implicitly | 21:36 |
| xgerman | since with flavor we would need to replicate pools an multiple drivers | 21:36 |
| rm_work | xgerman: i'm not saying it's useless, i'm saying doing it that way is REDUDANT | 21:36 |
| xgerman | ok | 21:37 |
| rm_work | create LB; create Pool on LB; woo we've limited scope ... now create listener and link pool to it; woo we've limited scope again! | 21:37 |
| blogan | xgerman: flavors now and providers before, which is why with neutron-lbaas we scrapped the plans for all objects to be able to exist independently | 21:37 |
| blogan | except creating the LB first lets us know what driver we should create the pool with | 21:38 |
| xgerman | yep, and I like that concept | 21:38 |
| rm_work | ah i see what xgerman means | 21:38 |
| rm_work | thanks for the clarification blogan | 21:39 |
| rm_work | yeah that could be problematic if that is not what we want | 21:39 |
| sbalukoff | ... | 21:39 |
| blogan | i woudl prefer it, but since lbaas supports multiple drivers, it then turns into a huge orchestration ordeal | 21:39 |
| xgerman | well, it causes problems since then you have health checks from different providers and need to fuse them | 21:39 |
| xgerman | blogan heat? | 21:39 |
| rm_work | >_> | 21:39 |
| sbalukoff | ...and this is what I was referring to by 'can of worms' | 21:40 |
| * blogan throws xgerman on heat | 21:40 | |
| xgerman | well armando said no orchestration in neutron... | 21:40 |
| sbalukoff | Good thing Octavia is not in neutron. ;) | 21:40 |
| xgerman | well, once you complete the 10 step program | 21:41 |
| rm_work | ugh | 21:41 |
| rm_work | fuck it | 21:41 |
| blogan | octavia is in the neutron stadium... | 21:41 |
| rm_work | I see how we got to the hideous compromise that is pools->LB | 21:41 |
| xgerman | blogan +1 | 21:41 |
| sbalukoff | Ok, I'm already well in to "hangry" at this point... Anyone need anything else from me before I break for lunch? | 21:41 |
| blogan | rm_work: i'm with you too, i dont like it but the only thing i can't solve is how do you get around not having to create a pool of an l7policy | 21:41 |
| rm_work | sbalukoff: fuck it, you win, +1 | 21:41 |
| rm_work | I'm still not happy ._< | 21:41 |
| rm_work | i feel like this one is going to haunt us | 21:42 |
| sbalukoff | rm_work: which is the same hideous compromise that is listeners -> LB, when it comes right down to it. ;) | 21:42 |
| xgerman | rm_work language — there might be minors on that channel | 21:42 |
| rm_work | sbalukoff: don't push it :P | 21:42 |
| blogan | sbalukoff: would you like to discuss why trump will be the best president ever? | 21:42 |
| sbalukoff | blogan: I will destroy you. | 21:42 |
| blogan | lol | 21:42 |
| sbalukoff | And not through language. | 21:42 |
| xgerman | trump/palin 2016 | 21:42 |
| blogan | the dream team! | 21:42 |
| sbalukoff | rm_work: In all seriousness, if you can think of any ways this is going to haunt us that the listener -> LB relationship isn't already going to haunt us, I want to hear about them. | 21:43 |
| *** crc32 has quit IRC | 21:43 | |
| blogan | sbalukoff: i think it'll haunt us when we go to independent listeners | 21:44 |
| blogan | err shared listeners | 21:44 |
| sbalukoff | blogan: Yep. | 21:44 |
| blogan | sorry | 21:44 |
| rm_work | yes | 21:44 |
| blogan | lbaas v3? | 21:44 |
| rm_work | one of my points was that when we switch to shared stuff across LBs, this will be a *problematic* limiting of scope | 21:44 |
| rm_work | that we wouldn't want | 21:45 |
| sbalukoff | rm_work: I agree. And I did have the choice of making pools truly abstract objects that are not associated with anything. But I didn't go down that path this time because I already knew that shared pools would be hard enough to get in, and when you look at the code, absolutely everthing everywhere wants to know which loadbalancer (singular) it's on. | 21:46 |
| sbalukoff | It would have involved... a lot more for loops. | 21:46 |
| sbalukoff | ;) | 21:46 |
| *** TrevorV has quit IRC | 21:46 | |
| rm_work | heh | 21:46 |
| rm_work | well, that is what i would rather see | 21:46 |
| *** madhu_ak has joined #openstack-lbaas | 21:46 | |
| sbalukoff | rm_work: If there's demand, we can look into it next cycle, IMO. :/ | 21:47 |
| blogan | sbalukoff: not to mention, in neutron-lbaas's case, it'd be tough to get that in due to the driver on the lb issue | 21:47 |
| sbalukoff | Again, I expect it'll be almost exactly the same amount of work as making listeners independent of loadbalancers. | 21:47 |
| blogan | and we're going to have that same issue with shared listeners | 21:47 |
| sbalukoff | blogan: Yep. | 21:47 |
| sbalukoff | This is something we can potentially accomplish in Octavia easier. | 21:47 |
| *** pcaruana has joined #openstack-lbaas | 21:48 | |
| blogan | if we didnt allow for multiple drivers, it'd be easy | 21:48 |
| sbalukoff | well... easier. ;) | 21:48 |
| rm_work | T_T | 21:48 |
| rm_work | yeah | 21:48 |
| blogan | but octavia should perhaps handle multiple drivers | 21:48 |
| rm_work | but then we'll have to deprecate THIS | 21:48 |
| rm_work | and the cycle of hacks and deprecations continues | 21:48 |
| sbalukoff | blogan: which means we should make the driver inteface friendly to the independent listeners concept. | 21:49 |
| sbalukoff | rm_work: It's hard to build Rome in a day. | 21:49 |
| blogan | sbalukoff: how so? | 21:49 |
| sbalukoff | blogan: I've not hashed out how that would work, exactly. | 21:49 |
| *** doug-fish has quit IRC | 21:49 | |
| sbalukoff | blogan: My mind has been on trying to make L7 work this cycle. | 21:49 |
| sbalukoff | In a way that doesn't paint us into a corner any worse than we're already painted into a corner. | 21:50 |
| blogan | sbalukoff: yeah i think there's basically create a single listener object to an entire loadbalancer graph that the driver will have to handle | 21:50 |
| blogan | which means...orchestration | 21:50 |
| sbalukoff | Yep. | 21:50 |
| blogan | but we might be able to make use of the single create call | 21:50 |
| sbalukoff | Yeah, there would be a lot of code re-use. | 21:50 |
| blogan | if that asshole ever finishes it | 21:50 |
| sbalukoff | But it's another fundamental shift in how we think about things that will be as uncomfortable as this shared pools / independent pools shift is. | 21:51 |
| a2hill | lol, sorry, i was going to get to it when i could | 21:51 |
| a2hill | >< | 21:51 |
| sbalukoff | HAHA | 21:51 |
| a2hill | :P | 21:51 |
| blogan | meh the problem i have with it is pools to me are children of listeners and i still don't see you're argument that they are not, so lets not rehash it :) | 21:52 |
| blogan | a2hill = asshole 2 hill | 21:52 |
| sbalukoff | Ok. | 21:52 |
| blogan | a2hole | 21:52 |
| a2hill | lol | 21:52 |
| *** rcernin has joined #openstack-lbaas | 21:53 | |
| sbalukoff | I think fundamentally-- I think of most of these things as a graph and not a hierarchy. We've chosen to artificially limit that graph when it comes to the listener -> LB relationship because it vastly simplifies things for us. | 21:53 |
| blogan | well even if LB -> Listener is M:N i'd still see it as a hierarchical graph :) | 21:54 |
| xgerman | well, we can always make edges a reource | 21:55 |
| sbalukoff | (Technically we've also reduced that graph to a hierarchy in the pool -> member relationship. But this again, simplifies things for us, and if a member IP/port does get re-used between two pools, it's not *that* expensive to have to do health checks and whatnot twice on it.) | 21:55 |
| sbalukoff | xgerman: +1 | 21:55 |
| blogan | sbalukoff: so do some loadbalancing software allow health checks of single members? | 21:56 |
| xgerman | probably | 21:56 |
| sbalukoff | blogan: As long as they're on the same appliance, yes. | 21:56 |
| xgerman | or a pool of one | 21:56 |
| sbalukoff | Yep. | 21:56 |
| blogan | meaning put a health check directly on a member, and not within the context of a pool | 21:56 |
| blogan | a pool of one is still a pool | 21:56 |
| blogan | a member without a pool is what i'm talking about | 21:56 |
| sbalukoff | blogan: Right. But again, we don't support that. ;) | 21:56 |
| xgerman | members top level objects... | 21:56 |
| xgerman | we just make /member | 21:57 |
| blogan | the permutations hurts me wee brain | 21:57 |
| sbalukoff | members top level objects is more trouble than it's worth. :) | 21:57 |
| sbalukoff | It's a matter of deciding where dealing with M:N relationships is truly worthwhile. | 21:57 |
| xgerman | and then have edge/123 with (member-id, listener-id) | 21:57 |
| blogan | multiple vips it will be, l7 it will be | 21:58 |
| sbalukoff | Yep, I think so. | 21:58 |
| blogan | instead of shared listeners, we could always just add an "additonal_vips" field on the load balancer | 21:58 |
| sbalukoff | So... we'll get L7 this cycle, and look into whether there's demand for multiple vips next cycle, eh? | 21:58 |
| sbalukoff | blogan: And keep things in the scope of a loadbalancer? | 21:58 |
| blogan | sbalukoff: yeah | 21:58 |
| xgerman | yep, let real customers/users decide | 21:58 |
| blogan | sbalukoff: it'd be ugly though | 21:59 |
| sbalukoff | (which solves the driver association problem.) | 21:59 |
| xgerman | can’t we have different drivers on the same VIP? Come on | 21:59 |
| sbalukoff | sbalukoff: It would probably be less ugly than completely overhauling the driver interface. But I don't know that yet... | 21:59 |
| blogan | xgerman: no! | 21:59 |
| blogan | blogan: i like to talk to myself | 21:59 |
| sbalukoff | xgerman: Are you cruising for a bruising too? | 21:59 |
| * xgerman ducks | 22:00 | |
| *** jwarendt has quit IRC | 22:01 | |
| blogan | sbalukoff: one last attempt at the pools thing, strictly neutron-lbaas this time | 22:01 |
| sbalukoff | Ok. | 22:01 |
| a2hill | On another note i've made my case a couple times in the tripleo channel, not sure when thats going in, so everythings sorta on hold till then :( | 22:01 |
| *** minwang2 has quit IRC | 22:01 | |
| sbalukoff | a2hill: I thought I saw a +2 on your patch? | 22:01 |
| blogan | workflow -> create lb -> create listener -> create l7 policy, create pool with associtiation to that l7 policy | 22:01 |
| a2hill | There was one +2 | 22:01 |
| *** minwang2 has joined #openstack-lbaas | 22:02 | |
| a2hill | but nobody else is responding in channel and no activity for a while, so while its been expressed as critical, it may be a while | 22:02 |
| sbalukoff | blogan: You can do that, but you'll have to set the l7policy action to something other that 'redirect to pool' initially (ie. you could set it to 'reject') at creation time. | 22:02 |
| sbalukoff | blogan: Er... | 22:02 |
| blogan | sbalukoff: you mean for some policies you need to have a pool as part of validation? | 22:03 |
| sbalukoff | blogan: Ok, you can do *close* to what you've described. It would actually look like this, if I understand evgeny's code there correctly: | 22:03 |
| sbalukoff | blogan: create lb -> create listner -> create l7policy (reject) -> create pool -> update l7policy (redirect to pool) | 22:03 |
| blogan | sbalukoff: bc redirect to pool will fail if no pool is specified? | 22:04 |
| sbalukoff | blogan: Yes, if your policy action is 'redirect to pool' we validate that a 'redirect_pool_id' is present and references a pool on the same loadbalancer. | 22:04 |
| * blogan flips table | 22:04 | |
| sbalukoff | Er... what? | 22:04 |
| blogan | there's not a good solution that will satisfy my needs | 22:05 |
| blogan | so pool on lb may just be the best way to do it | 22:05 |
| sbalukoff | Well... I *thought* the solution I gave was good. :/ | 22:06 |
| blogan | sbalukoff: its not perfect! | 22:06 |
| sbalukoff | ... and I happen to think that pool on LB is a good way to go (so long as we're limiting listener to a LB as well.) | 22:06 |
| sbalukoff | blogan: Is anything ever perfect? | 22:06 |
| blogan | sbalukoff: like i said i'm not strongly opposed to it, but just wanted to hash it out to see if we could come up with something that would make me feel better | 22:07 |
| a2hill | cause icky? | 22:07 |
| a2hill | :) | 22:07 |
| blogan | if we just put a flavor/driver on every entity, that'd solve everything | 22:07 |
| a2hill | full circle | 22:07 |
| sbalukoff | Well... rm_work is right that we *are* artificially limiting scope to a load balancer. But I think we've established that we have good reasons for doing so? | 22:07 |
| xgerman | yep | 22:08 |
| sbalukoff | Haha! | 22:08 |
| rm_work | >_< | 22:08 |
| sbalukoff | Yummy flavors! | 22:08 |
| blogan | if core neutron allowed multiple core plugins, they'd deal with the same issues we are | 22:08 |
| xgerman | yeah, flavors — maybe jwarendt will do a talk on it in Austin and we can all heckel | 22:08 |
| blogan | but they only allow one | 22:08 |
| sbalukoff | blogan: That's probably true! | 22:09 |
| xgerman | well, multiple drivers is important | 22:09 |
| blogan | xgerman: if its so important why doesn't neutron do it? hmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm? | 22:09 |
| sbalukoff | Haha! | 22:09 |
| * blogan waits for the ml2 allows it argument | 22:09 | |
| * blogan shushes himself | 22:10 | |
| sbalukoff | Haha | 22:10 |
| xgerman | armax said he had big plans for flavors | 22:10 |
| sbalukoff | DVR will solve everything. | 22:10 |
| xgerman | it’s now all in his camp | 22:10 |
| xgerman | sbalukoff it already did | 22:10 |
| blogan | armax is going to open up a baskin robbins? | 22:10 |
| xgerman | possibly | 22:11 |
| sbalukoff | Ok! Anything else right now? (I'mma go get some lunch if not...) | 22:12 |
| xgerman | I think it’s too late for lunch - you gotta wait for dinner | 22:12 |
| sbalukoff | xgerman: But... I didn't have breakfast either. ;_; | 22:13 |
| xgerman | lol | 22:13 |
| sbalukoff | And I have company for dinner... we're going to do sous vide chicken! | 22:13 |
| xgerman | nice — I will be sitting in a plane | 22:13 |
| sbalukoff | xgerman: I'm so sorry! | 22:14 |
| blogan | everyone's all in the sous vide lately | 22:14 |
| xgerman | I have a microwave | 22:14 |
| blogan | just put a pot of water in the microwave with your chicken | 22:15 |
| sbalukoff | Haha! | 22:15 |
| sbalukoff | blogan: But this way I get to look down my nose at you philistines! | 22:15 |
| xgerman | blogan probably has a smoker... | 22:16 |
| sbalukoff | Ok, folks! I'll be back on in an hour or so if you want me to strong-arm you into another decision. ;) | 22:16 |
| blogan | sbalukoff: i've been beaten down by the lack of the perfect solution | 22:17 |
| openstackgerrit | Aishwarya Thangappa proposed openstack/neutron-lbaas: Adding "region and endpoint_type" parameters to barbican_acl.py https://review.openstack.org/271544 | 22:18 |
| xgerman | unicorns | 22:18 |
| *** rtheis has quit IRC | 22:18 | |
| sbalukoff | blogan: Well, take heart in the fact that L7 functionality is awesome and powerful... and if we keep at this we'll even be able to showcase it at mitaka. :) | 22:19 |
| sbalukoff | Ok, BBIAB. | 22:19 |
| rm_work | sbalukoff: yep same as blogan | 22:29 |
| rm_work | i dgaf anymore | 22:29 |
| rm_work | it isn't great but it's temporarily workable >_> | 22:29 |
| blogan | dgaf = don't grow ass food? | 22:31 |
| rm_work | correct, I do not | 22:32 |
| rm_work | bbiab | 22:32 |
| blogan | rm_work: anymore, but you've implied that you did | 22:34 |
| *** crc32 has joined #openstack-lbaas | 22:41 | |
| *** rcernin has quit IRC | 22:53 | |
| openstackgerrit | Michael Johnson proposed openstack/octavia: Don't always run Octavia amphroa image build https://review.openstack.org/267663 | 22:57 |
| *** ducttape_ has quit IRC | 23:11 | |
| *** neelashah has quit IRC | 23:12 | |
| *** neelashah has joined #openstack-lbaas | 23:12 | |
| *** neelashah has quit IRC | 23:17 | |
| *** johnsom_ has joined #openstack-lbaas | 23:21 | |
| openstackgerrit | Banashankar k proposed openstack/octavia: Need to change the length of name in the algorithm since we are updating the lenght of the lb_algorithm in pool table we need to change the name column in algorithm table as its a FK. https://review.openstack.org/271178 | 23:22 |
| johnsom_ | sbalukoff Heads up, I'm reviewing active/active on the train home. (may have network drops, fyi) | 23:22 |
| *** shakamunyi has quit IRC | 23:22 | |
| johnsom_ | The distributor spec isn't really a spec, so I'm going to comment on that. I think we have more work to do here. | 23:22 |
| sbalukoff | johnsom_: Thanks! | 23:23 |
| *** fnaval_ has quit IRC | 23:27 | |
| *** neelashah has joined #openstack-lbaas | 23:28 | |
| *** neelashah has quit IRC | 23:33 | |
| *** fnaval has joined #openstack-lbaas | 23:40 | |
| *** neelashah has joined #openstack-lbaas | 23:44 | |
| *** neelashah has quit IRC | 23:48 | |
| *** fnaval has quit IRC | 23:51 | |
| *** fnaval has joined #openstack-lbaas | 23:52 | |
| *** blogan__ has joined #openstack-lbaas | 23:56 | |
| *** blogan_ has quit IRC | 23:56 | |
| *** bana_k has quit IRC | 23:59 | |
| *** bana_k has joined #openstack-lbaas | 23:59 | |
| *** neelashah has joined #openstack-lbaas | 23:59 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!
