| *** maciejjozefczyk has quit IRC | 00:22 | |
| *** AlexStaf has quit IRC | 00:38 | |
| *** AlexStaf has joined #openstack-lbaas | 00:39 | |
| rm_work | Yeah just some I think | 01:26 |
|---|---|---|
| rm_work | Like flavor... | 01:26 |
| rm_work | Which I ran into in my patch | 01:26 |
| johnsom | Well, I have fixed the provider capability list | 01:28 |
| openstackgerrit | Michael Johnson proposed openstack/octavia master: Fix filtering for provider capabilities list API https://review.opendev.org/693760 | 01:35 |
| johnsom | Not sure if there is a cleaner way to do that, but it's really not bad as it is | 01:37 |
| rm_work | Ok, can you look at the flavor one as well? | 02:22 |
| rm_work | I wonder if Sam from the summit is around in ITC | 02:23 |
| rm_work | *IRC | 02:23 |
| rm_work | I need to talk with him about the AZ stuff ... And timing | 02:23 |
| rm_work | sorrison: hey, you around? :D | 02:31 |
| sorrison | rm_work: I am! | 02:32 |
| rm_work | sorrison: sweet! we had some further discussion around AZ stuff, we decided we want to do all of the config for them in the API | 02:32 |
| rm_work | no config file shenanigans | 02:32 |
| rm_work | so an API endpoint for admins to set up / configure Octavia AZs | 02:32 |
| rm_work | similar to flavors | 02:32 |
| sorrison | ok sure thing | 02:33 |
| rm_work | i can definitely help | 02:33 |
| sorrison | I've got the workflow all working so I can now target an AZ on create. Haven't done any of the network mapping yet anyway | 02:33 |
| rm_work | cool! | 02:33 |
| rm_work | post your work in a CR :D | 02:33 |
| rm_work | just put WIP at the beginning of the commit summary | 02:34 |
| rm_work | if you want, i can help start on the API stuff | 02:34 |
| rm_work | or even just adding testing | 02:34 |
| rm_work | to move things along | 02:34 |
| rm_work | my timeline internally is ... aggressive | 02:34 |
| rm_work | but it seems like you're moving along at a good clip too, so maybe not necessary :D | 02:35 |
| rm_work | (we need this feature to launch a cloud in ... uhh, december) | 02:35 |
| johnsom | For WIP also set the workflow -1 flag so we can filter it out of review lists | 02:36 |
| openstackgerrit | Sam Morrison proposed openstack/octavia master: WIP Support creating a LB in a specified availability-zone https://review.opendev.org/693762 | 02:37 |
| rm_work | sweet | 02:37 |
| sorrison | I was about to start with tests for what I have now | 02:38 |
| johnsom | rm_work: look at the tls cipher story. It has all the tasks to add an api feature. Maybe you two can do parallel work on the az stuff | 02:38 |
| sorrison | rm_work: So you want to do the api for listing/creating AZs then? | 02:39 |
| rm_work | Yeah I figured I could add that in | 02:39 |
| sorrison | ok cool | 02:39 |
| rm_work | Either I can do it as a different patch below yours that you use, or I can just submit patchsets on your CR | 02:40 |
| sorrison | It also needs a little change in octavia-lib | 02:40 |
| rm_work | Whatever you're more comfortable with | 02:40 |
| rm_work | Yeah probably | 02:40 |
| sorrison | How about you do a separate patch that would go before mine? And then I can use it to plumb in the network | 02:40 |
| rm_work | Kk | 02:40 |
| rm_work | I'll start on that ASAP | 02:41 |
| sorrison | sounds good | 02:41 |
| rm_work | I'll just plan to have the necessary info in the DB/models for you to use, and assume you'll use it | 02:42 |
| sorrison | OK so you think basically instead of me passing around a availability zone string I'll pass around an AZ object which will have name/network etc. in it? | 02:47 |
| rm_work | yes | 02:55 |
| rm_work | or a dict generated from that | 02:55 |
| rm_work | or ... the individual vars? | 02:55 |
| rm_work | i'm not sure where/how you'll need to use it exactly | 02:56 |
| rm_work | currently deciding if I want to do a single "az_data" field like in flavor_data, or if i make it explicit fields | 02:56 |
| rm_work | explicit fields will be cleaner to use but require more migrations possibly in the future... but leaning that way | 02:59 |
| *** rcernin_ has joined #openstack-lbaas | 03:00 | |
| rm_work | basing all the API stuff on FlavorProfile as a template since it's pretty similar | 03:03 |
| *** rcernin has quit IRC | 03:03 | |
| sorrison | sounds good to me, you think you'll have something this week? | 03:06 |
| rm_work | i'm hoping to have something tomorrow | 03:07 |
| rm_work | or later today | 03:07 |
| rm_work | depending on your timezone :D | 03:07 |
| sorrison | nice! | 03:07 |
| sorrison | I'm only around for a couple more hours so I'll pick it up tomorrow hopefully | 03:08 |
| rm_work | kk yeah no worries | 03:08 |
| rm_work | I'll try to get at least something up, even if it's not done, but that will show the data models so you can start using them | 03:08 |
| rm_work | deciding also if our zones should be immutable or not | 03:09 |
| sorrison | first thoughts is that I feel they should be able to change, at least updating the network for an AZ although don't know if the network is needed after the amp is created | 03:24 |
| *** rcernin_ has quit IRC | 03:26 | |
| rm_work | only relevant on failover | 03:26 |
| rm_work | it would definitely make this simpler if they were immutable :D | 03:26 |
| rm_work | but I'll code for not | 03:26 |
| *** rcernin has joined #openstack-lbaas | 03:26 | |
| *** yamamoto has joined #openstack-lbaas | 03:31 | |
| *** yamamoto has quit IRC | 03:36 | |
| sorrison | Just trying to think with my day 2 operations hat on. As I can see a reason that the network would change for an AZ potentially but don't really know | 03:40 |
| rm_work | yep | 03:46 |
| *** ivve has joined #openstack-lbaas | 03:46 | |
| *** yamamoto has joined #openstack-lbaas | 03:48 | |
| rm_work | getting close | 04:02 |
| openstackgerrit | Adam Harwell proposed openstack/octavia master: WIP: Availability Zone admin API https://review.opendev.org/693765 | 04:15 |
| rm_work | sorrison: ^^ there is a first draft -- missing docs / releasenote, and maybe some testing? | 04:15 |
| rm_work | but should work | 04:15 |
| rm_work | appreciate your notes | 04:15 |
| rm_work | you too johnsom :D | 04:15 |
| *** tkajinam_ has joined #openstack-lbaas | 04:29 | |
| rm_work | sorrison: I added some TODOs with your name in them | 04:29 |
| sorrison | yip, reading through now | 04:29 |
| rm_work | you'll also need to add the FK to the az table in your migration | 04:29 |
| rm_work | but otherwise it's pretty straightforward I think | 04:29 |
| rm_work | we might need to make sure things are separated correctly, we have a pretty strict separation between DB access and certain parts of the code | 04:30 |
| rm_work | so if you see stuff where you're like "why didn't they just pass through the DB object", that's why | 04:30 |
| rm_work | a few of them are obvious, like we do json serialization | 04:30 |
| rm_work | but others might not be | 04:30 |
| rm_work | I'll take a look after you rebase | 04:31 |
| *** tkajinam has quit IRC | 04:32 | |
| rm_work | you might see some artifacts from the obvious flavor_profile->availability_zone copy-pasta, so call them out if you do :D | 04:32 |
| *** AlexStaf has quit IRC | 04:34 | |
| rm_work | oh, pep8 is most likely a complete mess :D | 04:39 |
| rm_work | gonna take a crack at that really quick | 04:39 |
| rm_work | before i sign off for the day | 04:39 |
| *** AlexStaf has joined #openstack-lbaas | 04:43 | |
| *** tkajinam_ has quit IRC | 04:58 | |
| *** tkajinam has joined #openstack-lbaas | 04:59 | |
| rm_work | ok fixed outstanding test failures | 05:54 |
| openstackgerrit | Adam Harwell proposed openstack/octavia master: WIP: Availability Zone admin API https://review.opendev.org/693765 | 05:55 |
| rm_work | should be good | 05:55 |
| *** ivve has quit IRC | 05:59 | |
| *** numans has quit IRC | 06:32 | |
| *** gcheresh_ has joined #openstack-lbaas | 06:37 | |
| *** armax has quit IRC | 07:01 | |
| *** ivve has joined #openstack-lbaas | 07:03 | |
| *** rcernin has quit IRC | 07:22 | |
| *** trident has quit IRC | 07:37 | |
| *** gcheresh_ has quit IRC | 07:45 | |
| *** trident has joined #openstack-lbaas | 07:48 | |
| *** gcheresh_ has joined #openstack-lbaas | 07:48 | |
| *** yamamoto has quit IRC | 07:53 | |
| *** yamamoto has joined #openstack-lbaas | 07:58 | |
| *** yamamoto has quit IRC | 08:01 | |
| *** yamamoto has joined #openstack-lbaas | 08:08 | |
| *** maciejjozefczyk has joined #openstack-lbaas | 08:09 | |
| *** yamamoto has quit IRC | 08:09 | |
| *** tesseract has joined #openstack-lbaas | 08:11 | |
| *** tkajinam has quit IRC | 08:37 | |
| *** yamamoto has joined #openstack-lbaas | 08:41 | |
| *** yamamoto has quit IRC | 08:46 | |
| *** numans_ has joined #openstack-lbaas | 08:55 | |
| *** rpittau|afk is now known as rpittau | 08:59 | |
| *** yamamoto has joined #openstack-lbaas | 09:13 | |
| *** ataraday_ has joined #openstack-lbaas | 09:21 | |
| *** irclogbot_2 has quit IRC | 09:39 | |
| *** irclogbot_1 has joined #openstack-lbaas | 09:40 | |
| *** yamamoto has quit IRC | 09:44 | |
| *** rcernin has joined #openstack-lbaas | 09:45 | |
| *** yamamoto has joined #openstack-lbaas | 09:53 | |
| *** yamamoto_ has joined #openstack-lbaas | 09:56 | |
| *** yamamoto has quit IRC | 09:57 | |
| *** yamamoto_ has quit IRC | 10:02 | |
| *** rcernin has quit IRC | 10:11 | |
| *** yamamoto has joined #openstack-lbaas | 10:29 | |
| *** yamamoto has quit IRC | 10:29 | |
| *** vesper has quit IRC | 10:30 | |
| *** vesper11 has joined #openstack-lbaas | 10:31 | |
| *** yamamoto has joined #openstack-lbaas | 10:47 | |
| *** rcernin has joined #openstack-lbaas | 10:50 | |
| *** ccamposr__ has quit IRC | 10:57 | |
| *** ccamposr__ has joined #openstack-lbaas | 10:59 | |
| *** yamamoto has quit IRC | 11:01 | |
| brtknr | anyone here able to tell me why neutron lbaas was removed completely? | 11:18 |
| brtknr | in Train? | 11:19 |
| brtknr | I understand Octavia is intended to replace Neutron LBaaS but what where the deciding factors? | 11:20 |
| brtknr | Did Neutron LBaaS have scaling issues or something of that kind? | 11:20 |
| *** rcernin has quit IRC | 11:26 | |
| *** ramishra has quit IRC | 11:35 | |
| openstackgerrit | Ann Taraday proposed openstack/python-octaviaclient master: Do not get all resources if ID is passed https://review.opendev.org/693144 | 11:52 |
| *** maciejjozefczyk has quit IRC | 12:04 | |
| *** yamamoto has joined #openstack-lbaas | 12:09 | |
| *** baffle has quit IRC | 12:38 | |
| *** openstackgerrit has quit IRC | 12:41 | |
| *** yamamoto has quit IRC | 12:44 | |
| *** henriqueof has quit IRC | 13:05 | |
| *** henriqueof has joined #openstack-lbaas | 13:08 | |
| *** lemko has joined #openstack-lbaas | 13:18 | |
| *** bcafarel has quit IRC | 13:24 | |
| *** maciejjozefczyk has joined #openstack-lbaas | 13:40 | |
| *** bcafarel has joined #openstack-lbaas | 13:50 | |
| *** baffle has joined #openstack-lbaas | 14:05 | |
| *** ivve has quit IRC | 14:22 | |
| *** gcheresh_ has quit IRC | 14:27 | |
| *** gcheresh_ has joined #openstack-lbaas | 14:33 | |
| frickler | brtknr: this should have most of the answers https://wiki.openstack.org/wiki/Neutron/LBaaS/Deprecation | 14:39 |
| *** TrevorV has joined #openstack-lbaas | 14:39 | |
| *** goldyfruit has joined #openstack-lbaas | 14:44 | |
| *** AlexStaf has quit IRC | 15:04 | |
| brtknr | frickler: thanks, is dual CA the recommended practice for prod? | 15:17 |
| *** armax has joined #openstack-lbaas | 15:27 | |
| *** pcaruana has joined #openstack-lbaas | 15:28 | |
| johnsom | brtknr: Yes, using dual CAs is more secure and blocks spoofing opportunities. | 15:39 |
| *** gcheresh_ has quit IRC | 15:51 | |
| *** paulbrowne has joined #openstack-lbaas | 16:30 | |
| *** tesseract has quit IRC | 16:32 | |
| *** AlexStaf has joined #openstack-lbaas | 16:38 | |
| *** ivve has joined #openstack-lbaas | 16:57 | |
| *** rpittau is now known as rpittau|afk | 17:00 | |
| johnsom | rm_work I looked at the flavors API, filtering is working fine there. It uses the normal filter code path where provider capabilities is a special case. | 17:01 |
| johnsom | Let me know if you have reproduction use case | 17:01 |
| *** pcaruana has quit IRC | 17:03 | |
| *** lemko has quit IRC | 17:22 | |
| *** ccamposr__ has quit IRC | 17:46 | |
| *** henriqueof has quit IRC | 17:47 | |
| *** ccamposr__ has joined #openstack-lbaas | 17:47 | |
| *** openstackgerrit has joined #openstack-lbaas | 18:03 | |
| openstackgerrit | Michael Johnson proposed openstack/octavia master: Fix filtering for provider capabilities list API https://review.opendev.org/693760 | 18:03 |
| *** paulbrowne has quit IRC | 18:14 | |
| *** ccamposr has joined #openstack-lbaas | 18:48 | |
| *** henriqueof has joined #openstack-lbaas | 18:50 | |
| *** ccamposr__ has quit IRC | 18:50 | |
| *** gcheresh_ has joined #openstack-lbaas | 19:47 | |
| *** armax has quit IRC | 20:20 | |
| *** armax has joined #openstack-lbaas | 20:22 | |
| openstackgerrit | Merged openstack/octavia stable/rocky: Improve the error message for bad pkcs12 bundles https://review.opendev.org/683966 | 20:29 |
| openstackgerrit | Merged openstack/octavia stable/stein: Improve the error message for bad pkcs12 bundles https://review.opendev.org/683954 | 20:29 |
| *** ataraday_ has quit IRC | 20:36 | |
| *** henriqueof1 has joined #openstack-lbaas | 20:38 | |
| *** henriqueof has quit IRC | 20:41 | |
| *** dosaboy has quit IRC | 21:07 | |
| rm_work | johnsom: yeah, my AZ/net patch shows it failing | 21:08 |
| *** TrevorV has quit IRC | 21:11 | |
| *** dosaboy has joined #openstack-lbaas | 21:13 | |
| *** rcernin has joined #openstack-lbaas | 21:17 | |
| rm_work | https://storage.bhs1.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_b48/692268/2/check/octavia-v2-dsvm-noop-py2-api/b483b6f/testr_results.html.gz | 21:17 |
| johnsom | rm_work That is what I just fixed in https://review.opendev.org/693760, the capabilities list. | 21:20 |
| rm_work | ah, you said provider | 21:21 |
| johnsom | Yeah, the test is maybe named a bit odd | 21:21 |
| johnsom | It's the flavor capability per provider API. lol | 21:21 |
| rm_work | it's not flavor capabilities? | 21:21 |
| rm_work | ah it's ... both, k | 21:21 |
| johnsom | Anyhow, that patch is ready for review and solves the issue | 21:22 |
| rm_work | yeah reviewing | 21:29 |
| openstackgerrit | Adam Harwell proposed openstack/octavia master: Let flavors override amp AZ/boot_network https://review.opendev.org/692268 | 21:32 |
| rm_work | johnsom: is "management_network" an amphora-driver only concept? | 21:33 |
| johnsom | lol, sigh, yeah, ok, brain short on that release note | 21:33 |
| rm_work | i wonder if that's problematic for putting in the AZ api | 21:34 |
| johnsom | yes | 21:34 |
| rm_work | because AZ should work for anything | 21:34 |
| rm_work | so... :/ | 21:34 |
| rm_work | need to think about that | 21:34 |
| johnsom | Just like amphora | 21:34 |
| johnsom | They are all hidden concepts that implement the driver | 21:34 |
| rm_work | yeah so making it mandatory is ... not possible | 21:35 |
| rm_work | even putting it on there is :/ | 21:35 |
| rm_work | maybe AZ really does need to be a JSON blob like flavor-profile | 21:35 |
| rm_work | eugh | 21:36 |
| openstackgerrit | Michael Johnson proposed openstack/octavia master: Fix filtering for provider capabilities list API https://review.opendev.org/693760 | 21:39 |
| johnsom | I could not let that release note go... | 21:40 |
| rm_work | lol yeah i figured you wouldn't :D | 21:41 |
| rm_work | so yeah, two things on AZs | 21:41 |
| johnsom | Strange, that didn't kick your rebase out of of the zuul queue. hmmm, well, it will still prove the point. | 21:42 |
| rm_work | 1) How/what should it take (as) config args? | 21:42 |
| rm_work | 2) What should it show to a user? | 21:42 |
| rm_work | Maybe just a description? | 21:42 |
| rm_work | it shouldn't show the user the management network, lol | 21:42 |
| rm_work | but it SHOULD show the nova zone? or not even? | 21:43 |
| johnsom | Right | 21:43 |
| rm_work | but the user would want to be able to select a zone to match their VMs | 21:43 |
| rm_work | *compute_zone | 21:43 |
| rm_work | I'm going to add a description I think, either way? | 21:44 |
| johnsom | It's odd as this is the first API addition that leaves the parameter to the provider interpretation. I.e. the API needs to be generic enough that it makes some sense to a HW appliance driver. | 21:44 |
| rm_work | yes | 21:44 |
| rm_work | I think `compute_zone` makes sense for anything | 21:44 |
| johnsom | This is partially why I was thinking it's just a flavors thing | 21:44 |
| rm_work | because even if it doesn't explicitly HAVE one, it might be racked for one | 21:44 |
| rm_work | but management network... :/ | 21:45 |
| johnsom | Well, a user should not need to specify that right? | 21:45 |
| rm_work | right | 21:45 |
| johnsom | With a flavor this is easy, they both go in the driver specific config for the flavor. | 21:46 |
| rm_work | yeah... | 21:46 |
| rm_work | it really is super similar to flavors... but just trying to alias out to match other services | 21:47 |
| rm_work | but also allow for multiple flavors to use the same AZ | 21:47 |
| rm_work | so as to not explode the number | 21:47 |
| rm_work | because we might want bronze/silver/gold for each AZ | 21:47 |
| rm_work | maybe give AZ a *flavor*? | 21:48 |
| rm_work | and leave management-net on the flavor | 21:48 |
| johnsom | Well, there is nothing stopping flavors from having the same AZ. | 21:48 |
| sorrison | works for me as our management net is shared between AZs | 21:49 |
| rm_work | err i meant | 21:49 |
| rm_work | multiple AZs for the same flavor, sorry | 21:49 |
| rm_work | is the issue | 21:49 |
| rm_work | we're going to have 3-4 AZs | 21:49 |
| johnsom | We need to have a way to set the lb-mgmt-net per AZ. Pretty sure of that | 21:49 |
| rm_work | and several flavors | 21:49 |
| rm_work | and it'd be multiplicative if AZ a flavor attribute | 21:50 |
| johnsom | Yeah, I get you. | 21:50 |
| rm_work | and also weird for users, lol | 21:50 |
| rm_work | so yeah, what if AZ had a flavor | 21:50 |
| rm_work | err no that is the same problem lol | 21:51 |
| johnsom | So, you want to define a list of AZs that are valid per provider. User sees name/description, behind the scenes it's ... hmmm, yeah, a bit like a flavor profile. | 21:51 |
| rm_work | eugh | 21:52 |
| johnsom | Well, an AZ having a flavor, doesn't make sense to me | 21:52 |
| rm_work | right, ignore that, i am still becoming fully conscious | 21:52 |
| johnsom | Yeah, so if you want to get all fancy on this, you could do something like flavor profile for the AZ technical definiton. | 21:53 |
| rm_work | i really wanted to avoid being fancy | 21:54 |
| sorrison | I think it makes sense for the network to be associated with the AZ as it's a location thing, where as flavor is a type of load balancer? | 21:54 |
| rm_work | yeah but if you think about a hardware LB, does it need a network? | 21:54 |
| rm_work | maybe??? | 21:54 |
| rm_work | I wish we had more provider drivers already in use so we could actually see if that makes sense | 21:54 |
| johnsom | sorrison Flavor is a per-load balancer customization pre-defined by the operator. It can override any option in the octavia.conf. | 21:54 |
| rm_work | also AvailabilityZones might need to override allowed_vip_networks for the amp driver | 21:55 |
| sorrison | If it helps our org also has F5s in 2 DCs, they have separate networks for each | 21:57 |
| *** gcheresh_ has quit IRC | 21:58 | |
| johnsom | rm_work the more you add in overrides for the AZs, the more it sounds like a flavor. | 21:58 |
| rm_work | yeah... | 21:59 |
| johnsom | Maybe you just clone over the flavor design, rename it AZ, and go from there | 21:59 |
| rm_work | but it also isn't >_> | 21:59 |
| rm_work | i mean... | 21:59 |
| rm_work | I kinda did | 21:59 |
| rm_work | but i was hoping it'd be a little more simplified | 21:59 |
| rm_work | I feel like those three things might be universal | 21:59 |
| rm_work | like, HW LBs would be tied to a compute zone, have a management net, and possibly advertise different vip-nets | 22:00 |
| rm_work | I could allow them to be nullable I guess | 22:00 |
| rm_work | except compute-zone | 22:00 |
| johnsom | Yeah, I am not sure compute zone is really a thing for appliances | 22:00 |
| sorrison | I thought a flavor and an AZ would map to our cinder and nova do azs and flavors (cinder calls them volume_types) | 22:01 |
| rm_work | isn't it? | 22:01 |
| rm_work | i mean, even if it's not explicitly IN nova or whatever, it still would be racked in a zone | 22:01 |
| sorrison | agree | 22:01 |
| johnsom | A network zone maybe | 22:01 |
| rm_work | ok, so you want just "zone"? | 22:02 |
| johnsom | https://docs.openstack.org/api-ref/network/v2/index.html?expanded=list-all-availability-zones-detail#list-all-availability-zones | 22:02 |
| rm_work | lol | 22:02 |
| rm_work | amphora driver can use it as compute zone, other drivers could use it as network zone | 22:02 |
| * rm_work shrugs | 22:02 | |
| johnsom | Well, that kind of defeats the purpose right. really you are going to need compute, network, etc. per AZ. | 22:02 |
| johnsom | I assumed AZ would also include configuration for network zone, not just compute | 22:03 |
| rm_work | that's kinda what management_network handles | 22:03 |
| sorrison | an az in neutron is for when creating networks and routers | 22:03 |
| johnsom | Wouldn't the network AZ be more about the VIP? | 22:03 |
| rm_work | both | 22:04 |
| rm_work | which is why i said also it'd need the allowed_vip_net too | 22:04 |
| johnsom | Yeah, ok, so create port doesn't have AZ as an option | 22:05 |
| johnsom | Got it. It's encapsulated in the network ID basically | 22:05 |
| rm_work | yeah | 22:06 |
| rm_work | looks like | 22:06 |
| johnsom | I keep coming back to the most flexible option would be build out the AZs like we did for flavors, so it encapsulates all of the required settings and they are defined per-driver. | 22:10 |
| rm_work | yeah... alright... it's just .... eugh | 22:14 |
| rm_work | the feedback i've generally gotten so far (and my experience using it) is that it's a bit cumbersome and confusing to explain | 22:14 |
| rm_work | but, that's probably because right now people only have one driver to use | 22:15 |
| rm_work | so it doesn't make a ton of sense | 22:15 |
| johnsom | Yeah, you would need to write a guide like I did for flavors | 22:15 |
| rm_work | alright.... well... I can do it | 22:16 |
| rm_work | just seems very overkill right now, but maybe not in the future? :/ | 22:16 |
| rm_work | it really seems like those three things -- compute_zone, management_net, allowed_vip_nets | 22:16 |
| rm_work | but yeah, i don't necessarily know all the things a HW LB might need | 22:17 |
| sorrison | I wonder if there is a need for an AZ to have a name and a compute_zone as I would think they would always be the same thing? | 22:17 |
| rm_work | i thought about that | 22:17 |
| rm_work | but I think so | 22:17 |
| johnsom | I'm thinking like chassis in the AZ as an example. I.e. maybe you have four appliance pairs per AZ | 22:17 |
| rm_work | tieing them 1:1 might not always work for people | 22:17 |
| johnsom | Yeah, I agree. plus the defaults in nova are, not really user friendly names. lol | 22:18 |
| sorrison | so multiple octacia AZs could map to the same nova AZ but have different networks? | 22:19 |
| sorrison | Makes it flexible which is always nice | 22:19 |
| rm_work | johnsom: so you want full-on az and az-capabilities? | 22:19 |
| rm_work | that's one use-case | 22:19 |
| sorrison | (we would actually probably fit that use case) | 22:20 |
| johnsom | rm_work Yeah, if it was me, I would do AZ and AZ profile (just to stay consistent naming) | 22:20 |
| rm_work | k FML | 22:20 |
| rm_work | alright | 22:20 |
| * rm_work does it | 22:20 | |
| johnsom | AZ/availability-zone/availability_zone/orbit Whatever you feel... grin | 22:20 |
| johnsom | AZ profile is the per-provider config, admin visible only. AZ is the user facing bit that maps to LBs. | 22:21 |
| johnsom | sorrison Does that make sense to you? Comments? | 22:21 |
| johnsom | rm_work and I tend to banter ideas around. I do want to make sure we get input, etc. | 22:22 |
| sorrison | yeah, I just can't figure out a use case that would require 2 AZs with the same settings off the top of my head | 22:22 |
| rm_work | it's not so much that we actually expect multiple AZs to use the same profile, honestly | 22:23 |
| rm_work | it's that profile is the abstraction away from capability lists | 22:23 |
| sorrison | ok so just more of a design thing to keep it consistent? | 22:23 |
| rm_work | I GUESS we could kinda flatten it | 22:23 |
| johnsom | The one case I can come up with (Yes, worked for a "megacorp" for 16 years) is branding. | 22:23 |
| johnsom | AZ1 becomes Shiny-AZ1-mega-zone | 22:23 |
| sorrison | haha yeah but under the covers its just the same old shit :-) | 22:24 |
| rm_work | johnsom: yeah i mean really, do we ever expect the same flavor-profile to be used by multiple flavors either? :/ | 22:24 |
| rm_work | it seems like it's just an abstraction to have an admin-object and a user-object | 22:24 |
| johnsom | Yeah, the other reason people asked for the flavor/flavor-profile split is to hide the "behind the scenes" settings from users. I.e. the operator can put dirty secrets in the profiles. Like "gold" flavor really maps to a raspberry-pi instance. | 22:25 |
| rm_work | right | 22:25 |
| rm_work | just to split the user/operator domains | 22:25 |
| rm_work | it's still most likely a 1:1 map | 22:25 |
| johnsom | Yeah, I would expect mostly 1:1, just edge cases you would cross map. | 22:26 |
| sorrison | in nova we just have the one object and depending on perms it will show you different fields etc. | 22:26 |
| rm_work | yeah that is what i was just thinking about | 22:27 |
| johnsom | Users trained to use AZ1 but you have really migrated that compute to a new DC with AZ5 in nova. That sort of thing | 22:27 |
| rm_work | like you see HV on a server if you're admin, otherwise you don't | 22:27 |
| sorrison | yeah | 22:27 |
| sorrison | having the multiple objects just makes things more complicated IMO | 22:28 |
| rm_work | yes, agree | 22:28 |
| rm_work | BUT | 22:28 |
| rm_work | being inconsistent is arguably *worse* | 22:28 |
| johnsom | People complain about those APIs with variable response formats. | 22:28 |
| sorrison | true | 22:28 |
| rm_work | so I am tempted to do it this way just to not have YET ANOTHER API MODEL | 22:28 |
| sorrison | I'm a sucker for consistency too | 22:28 |
| rm_work | I kinda wish we could revisit flavors now that I understand it better :D | 22:29 |
| rm_work | but alas | 22:29 |
| johnsom | Plus, creating the AZs should be a rare thing. It's mostly going to be the usage. | 22:29 |
| rm_work | yeah | 22:29 |
| rm_work | so, fine | 22:29 |
| rm_work | i'm just copying the entire model | 22:29 |
| rm_work | debating literally starting over and redoing the find/replace rofl | 22:29 |
| rm_work | rather than trying to stick back in some of the logic pieces i ripped out | 22:30 |
| johnsom | rm_work You probably want to incorporate this too: https://review.opendev.org/#/c/692427/ | 22:31 |
| rm_work | yeah | 22:31 |
| rm_work | i mean i'm just working from the files as-is | 22:31 |
| rm_work | so i should have that | 22:31 |
| rm_work | oh wait no i didn't | 22:31 |
| rm_work | not merged yet :D | 22:31 |
| rm_work | k | 22:31 |
| rm_work | uhh, do AZs need to be linked to a provider too then? | 22:33 |
| rm_work | *az-profiles | 22:33 |
| johnsom | Yeah, isn't that the point? | 22:37 |
| sorrison | Does a flavor profile override an az profile or the other way around? | 22:46 |
| rm_work | uhhh, lol | 22:49 |
| rm_work | i think AZ would overwrite flavor | 22:49 |
| rm_work | .... i think | 22:49 |
| johnsom | If they conflict it is a user error | 22:50 |
| johnsom | I.e. if the AZ is defined in the flavor but also on the command line, if they don't match, it's a direct user error. | 22:51 |
| johnsom | If you mean the settings in the profile itself, yeah, that is a new issue. I think you are right, if it's defined for AZ it would override the flavor setting, which overrides the octavia.conf default. lol | 22:52 |
| rm_work | >_< | 22:52 |
| *** tkajinam has joined #openstack-lbaas | 23:08 | |
| *** ivve has quit IRC | 23:25 | |
| *** goldyfruit has quit IRC | 23:28 | |
| *** maciejjozefczyk has quit IRC | 23:42 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!