| f0o | noonedeadpunk: reiterating on ovn-bgp; if I were to move the GatewayNodes onto the controllers, then I could move everything onto ovn-bgp and have them peer with the ToR routers which then go into the CRs. Do you happen to know if ovn-bgp supports unnumbered BGP? FRR does (as we use it extensively internally) | 06:43 |
|---|---|---|
| f0o | my biggest concern, if I remember correctly, is that ovn-bgp does try to mess with the frr config. if I could disable that and enable some "trust me bro"-config mode where it just dumps routes and not try to alter the frr config, that would really solve it | 06:44 |
| noonedeadpunk | it indeed does mess up with frr but kinda minorly | 07:15 |
| noonedeadpunk | I have no idea about unnumbered BGP. But surely - peering configuration is up to you | 07:16 |
| noonedeadpunk | so ovn-bgp pretty much needs router-id and in case of default "underlay" driver a vrf id it will be using | 07:17 |
| noonedeadpunk | "vrf" driver jsut allows to have multiple VRFs, and then VRF is configured in FRR as well | 07:17 |
| noonedeadpunk | also - ovn-bgp-agent can be enrolled on per-node basis basically | 07:18 |
| noonedeadpunk | so it's possible to limit it's effect for existing routers | 07:18 |
| noonedeadpunk | fwiw, I also had to configure PBR rules in FRR with underlay driver, as I didn't want node default route to be used for peering (which is assumed by default) | 07:19 |
| noonedeadpunk | s/driver/exposure method/ | 07:20 |
| f0o | interesting will have to check it more indepth | 09:19 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-rabbitmq_server master: Fail with human-readable errors if upgrade impossible https://review.opendev.org/c/openstack/openstack-ansible-rabbitmq_server/+/946232 | 09:34 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-rabbitmq_server master: Fail with human-readable errors if upgrade impossible https://review.opendev.org/c/openstack/openstack-ansible-rabbitmq_server/+/946232 | 09:37 |
| damiandabrowski | hey folks! I'm preparing patches for adding hashicorp vault/openbao support to ansible-role-pki and I wonder how to name new backend. | 09:56 |
| damiandabrowski | Currently we only have "standalone" backend, we are about to add a new one. | 09:57 |
| damiandabrowski | I have 3 options in mind: | 09:57 |
| damiandabrowski | a) hashicorp_vault - catchy name, but may be misleading because we also support openbao | 09:57 |
| damiandabrowski | b) openbao - in CI we will use openbao so this name makes sense from this perspective, but it may be misleading for hashicorp vault users | 09:57 |
| damiandabrowski | c) vault - more generic name, but it may not be precise enough | 09:57 |
| damiandabrowski | do you have any suggestions? | 09:57 |
| noonedeadpunk | jrosser: any opinions on that one? ^ | 09:58 |
| noonedeadpunk | as I'm ヽ(。_°)ノ | 09:58 |
| jrosser | omg | 09:58 |
| jrosser | ^ not in a bad way :) | 09:59 |
| noonedeadpunk | naming - biggest problem in tech world :D | 09:59 |
| jrosser | i kind of don't know what to suggest | 09:59 |
| jrosser | as we are currently totally in a big lawyering situation about exactly this issue | 10:00 |
| mossblaser | the risk of using 'vault' is that Hashicorp will still hassle you with trademark things | 10:00 |
| noonedeadpunk | I have one but damiandabrowski would not like what I'll be about to say, lol | 10:00 |
| noonedeadpunk | as it's a completely different thing, which is kinda different (but same) | 10:01 |
| noonedeadpunk | and that is "acme" backend... | 10:01 |
| jrosser | oh | 10:02 |
| noonedeadpunk | (forget about me saying that - it should be a different one anyway, I guess) | 10:02 |
| jrosser | oh right well yes | 10:02 |
| jrosser | this is using vault/bao as a certificate issuance thing? | 10:02 |
| noonedeadpunk | but both openbao and vault seems to support acme and certbot... | 10:02 |
| noonedeadpunk | yeah | 10:02 |
| mossblaser | if the role itself isn't actually deploying/configuring vault/bao it does seem acme is the right name (if that's what its really doing!) | 10:03 |
| noonedeadpunk | nah, it's not using acme per say | 10:03 |
| noonedeadpunk | (afaik) | 10:03 |
| noonedeadpunk | I learned that openbao can do acme and play nicely with certbot jsut this week | 10:04 |
| damiandabrowski | yeah, this role uses community.hashi_vault collection to get certificates from hashicorp_vault/oepnbao | 10:05 |
| damiandabrowski | it's also able to define certificate authorities and store them in hashicorp_vault/openbao | 10:05 |
| damiandabrowski | example: https://paste.citynetwork.se/etesocohucoxica.sql | 10:07 |
| noonedeadpunk | maybe we name it as `hashi_vault`? not sure about legal part still | 10:07 |
| noonedeadpunk | just to be in line with module naming, as given it's a community one... | 10:08 |
| damiandabrowski | grr, wrong paste | 10:08 |
| damiandabrowski | https://paste.opendev.org/raw/bARSOVpyNR3jJmiYJUFT/ | 10:08 |
| damiandabrowski | noonedeadpunk: indeed, i think it makes sense | 10:09 |
| noonedeadpunk | though task names like `Authenticate to Vault` should be revised for the concern mossblaser raised | 10:09 |
| noonedeadpunk | but basically any backend supported by module is supported by driver, which would manage some expectations I guess | 10:10 |
| mossblaser | "secret-store"? | 10:11 |
| noonedeadpunk | eh... barbican? | 10:11 |
| noonedeadpunk | if we don't want to have anything with hashi - then openbao is the only choice here I think | 10:14 |
| noonedeadpunk | as the implementation is very specific to the backend | 10:14 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-rabbitmq_server master: Ensure that failures are fatal for upgrade_check https://review.opendev.org/c/openstack/openstack-ansible-rabbitmq_server/+/946234 | 10:16 |
| damiandabrowski | yeah...that's right | 10:17 |
| damiandabrowski | okay folks, thanks for sharing your thoughts | 10:19 |
| damiandabrowski | so if no objections, I'll go with hashi_vault to match the ansible collection name that this backend depends on | 10:19 |
| damiandabrowski | if there are any arguments why not to use 'hashi_vault' name, we can stick with 'openbao' | 10:19 |
| noonedeadpunk | I gues we'll be able to rename it more or less painlessly? As it;s all mater of a single variable? | 10:28 |
| damiandabrowski | yeah, it shouldn't be a big deal | 10:40 |
| noonedeadpunk | it would be extremely nice to land that, so I could propose another bump of shas for the beta release: https://review.opendev.org/c/openstack/openstack-ansible-openstack_hosts/+/945569 | 13:09 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-rabbitmq_server master: Fix quorum/stream queues if they're below minimal size https://review.opendev.org/c/openstack/openstack-ansible-rabbitmq_server/+/946268 | 15:11 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-rabbitmq_server master: Execute rabbitmq post_upgrade hook https://review.opendev.org/c/openstack/openstack-ansible-rabbitmq_server/+/946270 | 15:16 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-rabbitmq_server master: Fix quorum/stream queues if they're below minimal size https://review.opendev.org/c/openstack/openstack-ansible-rabbitmq_server/+/946268 | 15:30 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-rabbitmq_server master: Execute rabbitmq post_upgrade hook https://review.opendev.org/c/openstack/openstack-ansible-rabbitmq_server/+/946270 | 15:30 |
| opendevreview | Merged openstack/openstack-ansible-openstack_hosts master: Switch release codename to Epoxy https://review.opendev.org/c/openstack/openstack-ansible-openstack_hosts/+/945569 | 15:42 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible master: Freeze roles for 31.0.0.0b1 release https://review.opendev.org/c/openstack/openstack-ansible/+/946083 | 15:51 |
| noonedeadpunk | this should be ready for the review now ^ | 16:06 |
| WireLost | folks, I see that Epoxy removed Linux Bridges and we must use OVN now (for real?)... Is OSA ready for it? | 16:12 |
| noonedeadpunk | WireLost: for OVN? Yes | 16:21 |
| noonedeadpunk | For migration? No | 16:21 |
| noonedeadpunk | For dropping linux bridges? Almost :D | 16:21 |
| noonedeadpunk | you also can use OVS... but yeah. migration is gonna be nasty | 16:21 |
| noonedeadpunk | The thing is that I kinda almost don't have LXB environments tbh, so even didn't look closely to migration path from LXB | 16:22 |
| noonedeadpunk | but even from OVS it's gonna be painful... | 16:22 |
| noonedeadpunk | one thing I still don't understand how to solve - is VIPs inside custokmer environments and requirement for allowed-address pair configuration for them to work in OVN | 16:23 |
| noonedeadpunk | and I know our users were just disabling port security instead of configuring allowed address pairs... | 16:24 |
| noonedeadpunk | but also I'm not sure about capacity of current maintainers for making such migration from LXB... So any contributions in this area are exteremely welcome. | 16:26 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible master: Unfreeze roles after milestone release https://review.opendev.org/c/openstack/openstack-ansible/+/946281 | 16:39 |
| WireLost | But OVN also requires OVS, right? It's for a new deployment, not migration lol | 17:10 |
| jrosser | WireLost: OVN has been the default in osa for a few releases now, so the CI jobs are testing the AIO config of that pretty well | 17:27 |
| jrosser | it’s just now for Epoxy we remove the non-default option of lxb | 17:27 |
| noonedeadpunk | (which we have no choice but remove) | 17:59 |
| noonedeadpunk | WireLost: well, jamesdenton has a good blog on how he migrated from lxb to ovn: https://www.jimmdenton.com/migrating-lxb-to-ovn/ | 18:00 |
| noonedeadpunk | it was a while ago though | 18:00 |
| WireLost | Cool, thanks! | 19:07 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!