| opendevreview | Merged openstack/ansible-role-systemd_networkd master: Don't make VLAN/VXLAN/MACVLAN mutually exclusive https://review.opendev.org/c/openstack/ansible-role-systemd_networkd/+/929346 | 00:58 |
|---|---|---|
| opendevreview | Dmitriy Rabotyagov proposed openstack/ansible-role-systemd_networkd stable/2024.1: Don't make VLAN/VXLAN/MACVLAN mutually exclusive https://review.opendev.org/c/openstack/ansible-role-systemd_networkd/+/930410 | 07:33 |
| jrosser | o/ good morning | 07:40 |
| noonedeadpunk | o/ | 07:47 |
| opendevreview | Merged openstack/openstack-ansible master: Add global release note for Apache MPM alignment https://review.opendev.org/c/openstack/openstack-ansible/+/930185 | 07:56 |
| noonedeadpunk | we also need that for skyline to land on master : https://review.opendev.org/c/openstack/openstack-ansible/+/929892 | 08:00 |
| noonedeadpunk | *skyline mpm fix | 08:00 |
| jrosser | so for zuul stable branches | 08:08 |
| jrosser | i think we need to do an experiment and find out what actually happens today with the depends on stuff (vs. what might have happened in the past) | 08:08 |
| opendevreview | Jonathan Rosser proposed openstack/openstack-ansible master: DNM - test git checkout of zuul repos https://review.opendev.org/c/openstack/openstack-ansible/+/930413 | 08:25 |
| noonedeadpunk | I think we'd need to have a hold node for such experiment | 08:25 |
| jrosser | ^ that should show the expected sha of master and 2024.1 | 08:26 |
| noonedeadpunk | and also I'm not sure what specifically you're checking with ^ | 08:26 |
| jrosser | then we can try adding a depends on, and see what happens | 08:26 |
| jrosser | i think that we are trying to understand the state of the prepared git repos when depends-on is in use | 08:26 |
| noonedeadpunk | Ah, I need to somehow explain better where I see the current "issue"... | 08:26 |
| noonedeadpunk | well, we kinda need to have a way to return "back" to the prepared state | 08:27 |
| jrosser | my understanding is that the branch positions are are modified to be the prepared state | 08:28 |
| noonedeadpunk | and even not for integrated repo, but all rest repos | 08:28 |
| jrosser | to allow that to happen | 08:28 |
| noonedeadpunk | yep | 08:28 |
| jrosser | ok | 08:28 |
| noonedeadpunk | but you can checkout from them anywhere easily | 08:28 |
| noonedeadpunk | the question I have - how to checkout back to prepared state which originally was | 08:28 |
| noonedeadpunk | for integrated repo specifically we do record it's state and can return back with that: https://opendev.org/openstack/openstack-ansible/src/branch/master/scripts/gate-check-commit.sh#L73 | 08:30 |
| jrosser | maybe i misunderstand, but i thought that checking out the branch would do that by magic | 08:30 |
| noonedeadpunk | and then we return back to it quite easily | 08:30 |
| noonedeadpunk | oh well, you mean create a new brach out of current HEAD... | 08:31 |
| noonedeadpunk | yeah, that will work as well | 08:31 |
| jrosser | more that the branch positions are adjusted by zuul as part of preparing the repos | 08:32 |
| jrosser | to account for depends-on | 08:32 |
| noonedeadpunk | yep, they are indeed | 08:32 |
| jrosser | ok so definatly i am missing what is wrong :) | 08:32 |
| noonedeadpunk | so we'd need to make automation to create new branches for all existing repos, then to checkout them all to UPGRADE_SOURCE_BRANCH, and return back for upgrade | 08:33 |
| noonedeadpunk | (all prepared by zuul repos) | 08:33 |
| noonedeadpunk | Highly likely that it's just me who thinks that's very complicated to do | 08:35 |
| jrosser | hmmm | 08:37 |
| * jrosser confused | 08:37 | |
| jrosser | is this all to do with how we symlink the role dirs? | 08:40 |
| opendevreview | Merged openstack/openstack-ansible-repo_server master: Ensure that selected Apache MPM is enforced https://review.opendev.org/c/openstack/openstack-ansible-repo_server/+/929690 | 08:51 |
| jrosser | imho we should reduce the complexity, almost certainly at the expense of some supposed optimisiation | 08:55 |
| opendevreview | Merged openstack/openstack-ansible-os_neutron stable/2024.1: Disable uWSGI usage by default https://review.opendev.org/c/openstack/openstack-ansible-os_neutron/+/929549 | 08:55 |
| jrosser | having two different situations to deal with (upgrade source and target branch) only makes things much more difficult to understand | 08:56 |
| jrosser | if i now understand properly it is that for !master branch, a-r-r and a-c-r is not matching the prepared branches in the zuul repos? | 08:57 |
| noonedeadpunk | so IIRC for N-1 we jsut fetch everything from gitea | 08:58 |
| noonedeadpunk | and then on N we do use prepared repos | 08:58 |
| jrosser | perhaps a different way to look at this is we should strip all of the "in zuul" handling out of get-ansible-role-requirements.yml | 08:58 |
| noonedeadpunk | oh, that's a good one | 08:59 |
| noonedeadpunk | as in fact we should | 08:59 |
| jrosser | and there is a separate thing, which determines if the zuul repo branch != the a-r-r / a-c-r one, and drops the required user-role-requriements to make that work properly | 08:59 |
| noonedeadpunk | potentially, by placing user-role-requirements | 08:59 |
| noonedeadpunk | yeah | 08:59 |
| jrosser | that would be pretty simple, and would work for all branches | 08:59 |
| jrosser | and this business of symlink / delete dirs / but only sometimes is just added complexity and confusion | 09:00 |
| noonedeadpunk | and code there is not readable at all either | 09:00 |
| noonedeadpunk | this in any way doesn't solve our u-c thing on upgrade though :D | 09:01 |
| jrosser | so i would be in favour of now leveraging the user-role-requirements / user-collection-requriements (primarily in N-1 branches) to ensure we use the correct zuul branches and not the specific sha | 09:01 |
| jrosser | well thats another issue | 09:02 |
| jrosser | and i think seperate? | 09:02 |
| noonedeadpunk | totally separate | 09:02 |
| noonedeadpunk | also - I'm not 100% sure about anu stable branch - as collections at least were improved couple of times | 09:03 |
| noonedeadpunk | ie - to allow avoid some role clones at all | 09:03 |
| noonedeadpunk | but I think we should be leveraging them only on master as well? | 09:03 |
| noonedeadpunk | as actually all the complexity in get-ansible-role-requirements is related to master? | 09:04 |
| jrosser | it is | 09:04 |
| jrosser | well we can handle that too - dropping a symlink and setting up user-role-requirements to not clone at all? I think it can do that | 09:05 |
| jrosser | and you would do that if the checked out sha/branch in the zuul repo was the one you wanted | 09:06 |
| noonedeadpunk | oh, yeah. true | 09:12 |
| jrosser | maybe i miss something but is it as simple as rewriting the a-r-r file to user-collection-requirements, fixing the url to be something like file:// and updating the version to be $branchname | 09:12 |
| jrosser | that would be brute force but would work | 09:12 |
| noonedeadpunk | and jsut be part of gate-check-commit | 09:13 |
| noonedeadpunk | yeah | 09:13 |
| jrosser | huh | 09:13 |
| jrosser | maybe that makes a ton of stuff easier to understand | 09:13 |
| noonedeadpunk | or? I thought that we never want to have trhe Zuul logic outside of CI | 09:13 |
| noonedeadpunk | so basically this whole block can go away https://opendev.org/openstack/openstack-ansible/src/branch/master/scripts/get-ansible-role-requirements.yml#L54-L102 | 09:14 |
| jrosser | that would be ideal, but perhaps difficult as both phases of the upgrade are run in the one script | 09:14 |
| opendevreview | Merged openstack/openstack-ansible-os_neutron stable/2023.2: Do not kill ipsec on L3 cleanup https://review.opendev.org/c/openstack/openstack-ansible-os_neutron/+/930186 | 09:14 |
| jrosser | so you need to be able to prepare at least the target branch user-role-requirements after the source branch run is done | 09:15 |
| * noonedeadpunk also have a feeling now that we're talking about different issues right now | 09:15 | |
| jrosser | or at minimum, copy them into place | 09:15 |
| jrosser | perhaps indeed :) | 09:15 |
| jrosser | i thought you were suggesting not having "in zuul" handling in gate-check-commit either | 09:15 |
| jrosser | so perhaps doing all this stuff in the pre- playbooks? | 09:16 |
| noonedeadpunk | I think it' fine to have that in gate-check-commit | 09:17 |
| noonedeadpunk | or well, pre-playbook is also a very good place | 09:17 |
| noonedeadpunk | that is good idea | 09:17 |
| opendevreview | Merged openstack/openstack-ansible-ceph_client master: Manage apt repositores and keys using deb822_repository module https://review.opendev.org/c/openstack/openstack-ansible-ceph_client/+/929622 | 09:17 |
| noonedeadpunk | but then it indeed can be hard to mange pre-upgrade post-upgrade versions | 09:17 |
| jrosser | maybe some config files are prepared in the -pre playbooks and then moved into place if they exist in gate-check-commit | 09:18 |
| noonedeadpunk | if going baby steps, first patch would be just to clean-up `get-ansible-role-requirements` from zuul-related mess into a separate thing | 09:18 |
| noonedeadpunk | in favor of generation of u-r-r | 09:19 |
| jrosser | yes | 09:19 |
| noonedeadpunk | and then this new thing can evolve to better handle upgrade cases? | 09:19 |
| jrosser | sounds good | 09:19 |
| noonedeadpunk | well, the thing is that it's gate-check-commit then who should manage checkouts of repos | 09:20 |
| noonedeadpunk | or trigger smth which will do it | 09:21 |
| opendevreview | Merged openstack/openstack-ansible-openstack_hosts master: Vendor osbpo gpg key into the role https://review.opendev.org/c/openstack/openstack-ansible-openstack_hosts/+/930280 | 09:21 |
| opendevreview | Merged openstack/openstack-ansible-openstack_hosts master: Ensure python libselinux bindings for containers https://review.opendev.org/c/openstack/openstack-ansible-openstack_hosts/+/929540 | 09:21 |
| noonedeadpunk | as checkout back should be done after install of N-1 is done but before N is bootstrapped. And this all happens in gate-check-commit | 09:22 |
| noonedeadpunk | or well, could be that u-c is a very unique case we have | 09:22 |
| noonedeadpunk | so cases we have, which could act differently and have slightly different behaviour: roles, collections, u-c and services | 09:26 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-openstack_hosts stable/2024.1: Ensure python libselinux bindings for containers https://review.opendev.org/c/openstack/openstack-ansible-openstack_hosts/+/930421 | 09:29 |
| jrosser | we should note this all on the etherpad | 09:29 |
| noonedeadpunk | https://etherpad.opendev.org/p/osa-zuul-checkout-refactoring ? | 09:29 |
| jrosser | as we have (supposedly) already got handling for u-c in zuul | 09:30 |
| jrosser | here https://github.com/openstack/openstack-ansible/blob/master/scripts/bootstrap-ansible.sh#L133-L142 | 09:30 |
| noonedeadpunk | we have for all these bits | 09:30 |
| jrosser | and here https://github.com/openstack/openstack-ansible-repo_server/blob/master/tasks/repo_install_constraints.yml#L23-L39 | 09:30 |
| jrosser | but it's not working for $reasons | 09:30 |
| noonedeadpunk | not working on N-1 as we undefine ZUUL_SRC_PATH | 09:31 |
| jrosser | argh right i see | 09:31 |
| jrosser | so this is yet another reason to have a unified approach for all branches | 09:31 |
| noonedeadpunk | https://opendev.org/openstack/openstack-ansible/src/branch/master/scripts/gate-check-commit.sh#L261-L267 | 09:32 |
| noonedeadpunk | but we have something else somewhere else as well I believe | 09:32 |
| noonedeadpunk | yeah, so we don't export it for upgrade at all: https://opendev.org/openstack/openstack-ansible/src/branch/master/zuul.d/playbooks/pre-osa-aio.yml#L44 | 09:33 |
| noonedeadpunk | so we explicitly avoid setting or running bootstrap-ansible for upgrade jobs, fully relying on gate-check-commit | 09:34 |
| noonedeadpunk | to checkout, bootstrap, deploy, set ZUUL_SRC_PATH, upgrade | 09:34 |
| jrosser | well - you've done more work on all this than me - but i do find the complexity totally overwhelming | 09:41 |
| noonedeadpunk | I will try to describe in etherpad | 09:41 |
| jrosser | there is in a way a lot of complexity when handling upgrade jobs | 09:41 |
| jrosser | but at the same time, a job which is !upgrade is just a subset of an upgrade job | 09:42 |
| noonedeadpunk | it's not _that_ complex, but complex enough if you want to completely refactor it | 09:42 |
| noonedeadpunk | well, I always was thinking about that in reverse, but looking at code I understand how it's reversed now | 09:43 |
| noonedeadpunk | feels like we'd need to move the etherpad to contributor docs once we're done | 09:47 |
| jrosser | i think we may have a rabbitmq breakage on noble | 09:54 |
| jrosser | seen this on two jobs now https://zuul.opendev.org/t/openstack/build/f2ebae81e6cb4f129855b166a07b7c36/log/job-output.txt#5581 | 09:55 |
| noonedeadpunk | what rabbitmq version get's in there? | 09:55 |
| noonedeadpunk | it feels to be coming not from repos we expect | 09:56 |
| jrosser | `rabbitmq-server=4.0.2-1` | 09:56 |
| noonedeadpunk | yeah | 09:56 |
| noonedeadpunk | explains it | 09:57 |
| noonedeadpunk | so quite a decision to take | 09:57 |
| noonedeadpunk | also nice release notes regarding support: https://github.com/rabbitmq/rabbitmq-server/releases/tag/v4.0.2 | 10:00 |
| noonedeadpunk | so the issue is following. 2024.2 is actually a good place for such upgrades, so we techincally can drop support of HA queues here | 10:03 |
| noonedeadpunk | and just leave CQv2 or Quorum queues | 10:03 |
| noonedeadpunk | but we have Quorum for just 2024.1 and I'm not confident enough in them | 10:03 |
| noonedeadpunk | (but look good so far) | 10:03 |
| noonedeadpunk | or, we would have to stay on 3.13 until 2025.1 kinda | 10:04 |
| noonedeadpunk | (or maybe not?) | 10:04 |
| noonedeadpunk | as it actually feels we need to somehow convert old haqueues to just CQv2 | 10:05 |
| noonedeadpunk | if user opted out from quorum | 10:05 |
| noonedeadpunk | and there's also interesting lhepri replacement for mnesia as well... | 10:07 |
| noonedeadpunk | jrosser: oh, I probably found what went wrong - https://opendev.org/openstack/openstack-ansible/blame/commit/e16d741a78ab75586f70034bc749a6a03a62689e/zuul.d/playbooks/run.yml#L31 | 10:14 |
| noonedeadpunk | as for upgrade jobs pre_run does not happen | 10:14 |
| noonedeadpunk | I'm actually not sure how it works at all.... | 10:14 |
| noonedeadpunk | ah, whatever, these are ignored, disregard | 10:15 |
| opendevreview | Merged openstack/openstack-ansible-os_neutron stable/2023.1: Do not kill ipsec on L3 cleanup https://review.opendev.org/c/openstack/openstack-ansible-os_neutron/+/930187 | 11:20 |
| opendevreview | Merged openstack/openstack-ansible-haproxy_server stable/2023.2: Respect defined interface for external VIP with LE https://review.opendev.org/c/openstack/openstack-ansible-haproxy_server/+/930385 | 11:22 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-rabbitmq_server master: Bump rabbitmq version to 3.13.7 https://review.opendev.org/c/openstack/openstack-ansible-rabbitmq_server/+/930446 | 12:06 |
| noonedeadpunk | this should fix noble rabbitmq ^ | 12:06 |
| jrosser | that is an ugly fallback to take completely the wrong version rather than failing | 12:10 |
| jrosser | well, "wrong" is our opinion i guess, apt has its own ideas :) | 12:11 |
| noonedeadpunk | yeah... | 12:11 |
| noonedeadpunk | but well, I think it has also smth to do with our pinning | 12:11 |
| noonedeadpunk | that's the policy I saw: https://paste.openstack.org/show/bFC2rhWoawUYeTOOdvnY/ | 12:12 |
| noonedeadpunk | so apt basically see there's nothing to increase priority on and proceeds with what it has | 12:12 |
| noonedeadpunk | so probably, we should drop the rest to some non-installable priority | 12:12 |
| noonedeadpunk | like set prio 1 or smth.... | 12:13 |
| noonedeadpunk | but then it will just take from the default repo instead | 12:13 |
| jrosser | oh that reminds me, we still could update the url of the ppa there | 12:14 |
| noonedeadpunk | oh, yes | 12:14 |
| noonedeadpunk | I have no idea though what's best to do | 12:14 |
| noonedeadpunk | as current repo seems quite reliable finally... | 12:14 |
| noonedeadpunk | we have seen 1 outage during 4.0 release time or so I think | 12:15 |
| noonedeadpunk | (when jobs were just timeouting) | 12:15 |
| opendevreview | Jonathan Rosser proposed openstack/ansible-hardening master: Apply architecture specific audit rules https://review.opendev.org/c/openstack/ansible-hardening/+/930451 | 12:34 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-os_octavia master: Align coordination_client_ssl value with other roles https://review.opendev.org/c/openstack/openstack-ansible-os_octavia/+/930464 | 13:32 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-os_octavia master: Move rpc_conn_pool_size to oslo_messaging_rabbit https://review.opendev.org/c/openstack/openstack-ansible-os_octavia/+/930469 | 13:40 |
| opendevreview | Merged openstack/openstack-ansible-galera_server master: Map all relevant architectures for deb822 repository setup https://review.opendev.org/c/openstack/openstack-ansible-galera_server/+/930282 | 14:36 |
| opendevreview | Merged openstack/openstack-ansible-ceph_client master: Ensure apparmor folder exists for ceph caching https://review.opendev.org/c/openstack/openstack-ansible-ceph_client/+/929606 | 14:52 |
| mnaser | jrosser, noonedeadpunk: https://review.opendev.org/c/openstack/openstack-ansible-os_nova/+/817222 seems like osa is one of the only tools which are using this feature, we're having issues with it because we rotate certs often (3 months automatically) and noticing that when the cert expires, qemu doesn't "read" the new cert, and then we start to get errors that the cert is expired for vnc.. have you seen something similar? unless | 14:58 |
| mnaser | you issue long lived cerst | 14:58 |
| noonedeadpunk | oh yes, by default cert is like 10y | 14:59 |
| noonedeadpunk | otherwise console is revived after live migration | 14:59 |
| noonedeadpunk | so 3m is not gonna really fly I guess | 14:59 |
| jrosser | is this a thing? https://patchwork.kernel.org/project/qemu-devel/patch/20210104071128.754-1-changzihao1@huawei.com/#23910013 | 15:00 |
| mnaser | urgh, that's annoying, we do 3 months so after a while we've seen now tls stops working of course until a live migration or any operation that gets reloaded | 15:01 |
| mnaser | jrosser: oh that's nice, i have been googling but couldnt find much | 15:02 |
| jrosser | its unclear if that actually went anywhere from that | 15:02 |
| mnaser | i think it has not :( | 15:02 |
| jrosser | doh :( | 15:02 |
| opendevreview | Damian Dąbrowski proposed openstack/openstack-ansible-os_octavia master: Disable octavia_management_net_dhcp by default https://review.opendev.org/c/openstack/openstack-ansible-os_octavia/+/930486 | 15:02 |
| mnaser | 3m auto-renewal feels really nice, switching to a 10y thing feels like a big hack boo | 15:03 |
| mnaser | the whole system we built was a sidecar that automatically renewed certs every 3 months for libvirt api and vnc | 15:04 |
| mnaser | or whatever period of time.. | 15:04 |
| jrosser | hmmm https://qemu-project.gitlab.io/qemu/interop/qemu-qmp-ref.html#qapidoc-1749 | 15:04 |
| mnaser | oh interesting let me git blame that | 15:05 |
| mnaser | https://github.com/qemu/qemu/commit/9cc07651655ee86eca41059f5ead8c4e5607c734 | 15:05 |
| mnaser | now i think with libvirt we're not supposed to technically talk to qmp of vms | 15:06 |
| mnaser | so i wonder if it can call display-reload | 15:06 |
| mnaser | https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/LDTM3NIOBWCS2USQSHXEKASHJHDVPNDG/ | 15:06 |
| jrosser | `virsh qemu-monitor-command ....` ? | 15:07 |
| mnaser | https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainGraphicsReload | 15:08 |
| mnaser | https://github.com/libvirt/libvirt/commit/b25b071c7551495882cb8970bccd3e31d16b3667 | 15:09 |
| mnaser | needs libvirt 10.2.0 and qemu 6.0.0 | 15:09 |
| jrosser | thats an api right? how would you invoke that from tooling that dropped a new cert? | 15:10 |
| opendevreview | Merged openstack/openstack-ansible-openstack_hosts master: Rename libselinux python package bindings https://review.opendev.org/c/openstack/openstack-ansible-openstack_hosts/+/929542 | 15:10 |
| mnaser | jrosser: i was thinking once we drop the new cert we would just list all domains and run that against all domains, since the tooling that rotates certs is a small daemon | 15:11 |
| mnaser | im thinking i might even right a small tool that would just watch the cert file and issue the command if it changes, that can be used by any deployemnt tool for example | 15:12 |
| mnaser | cause we manage/issue sidecars with this - https://github.com/vexxhost/pod-tls-sidecar | 15:13 |
| jrosser | mnaser: btw did you get anywhere with mcapi CI on noble? | 15:15 |
| * jrosser still needs virtualenv support for that | 15:15 | |
| mnaser | jrosser: we are slowly making our way with noble here, not as fast as i'd like to | 15:15 |
| mnaser | i've had a few family stuff last week that put me out for a while so slowly ramping up | 15:15 |
| mnaser | i do have noble in the zuul so that kinda helps at least a bit | 15:16 |
| jrosser | danger is we release OSA pointing to my personal fork of mcapi which would be baaaad | 15:16 |
| mnaser | what pieces are essential to it? sorry | 15:16 |
| jrosser | oh sorry, the k8s collection i mean | 15:16 |
| mnaser | ah that | 15:16 |
| mnaser | oh its the whole | 15:17 |
| mnaser | works in docker ci container thing right | 15:17 |
| jrosser | i think so yes, as somehow that doesnt count as a "system python" probably | 15:17 |
| noonedeadpunk | btw, very noob question I was not able to quickly google for - how in the world to select a driver for Magnum? As seems that's only config setting, so not smth you can do on tempalte level? | 15:28 |
| noonedeadpunk | ie, if to have both capi and heat drivers at same time for more granular migration? | 15:29 |
| jrosser | theres some tuple that identifies the driver i think (k8s, vm, ubuntu) or something -> capi driver | 15:30 |
| noonedeadpunk | that used to be like... based on image tags? | 15:30 |
| jrosser | i think it still is | 15:30 |
| noonedeadpunk | huh, ok | 15:31 |
| noonedeadpunk | so kinda if I just get capi driver in, in theory, existing cluster templates should remain working | 15:31 |
| jrosser | i think so..... but never actually had heat stuff working at all | 15:32 |
| noonedeadpunk | yeah, we still do have it working and ppl using it. So starting thinging about migration plan | 15:33 |
| noonedeadpunk | or well, possiiblity | 15:33 |
| mnaser | yes noonedeadpunk, it relies on the actual combination of coe when creating cluster template, and the os_distro from the image attrs | 15:45 |
| mnaser | its not a great solution but indeed it wouldn't affect any of the existing users that use fedora | 15:45 |
| noonedeadpunk | okay, awesome, thanks for confirmation! | 15:45 |
| opendevreview | Jonathan Rosser proposed openstack/openstack-ansible-os_horizon master: Ensure that selected Apache MPM is enforced https://review.opendev.org/c/openstack/openstack-ansible-os_horizon/+/929695 | 15:46 |
| opendevreview | Jonathan Rosser proposed openstack/openstack-ansible master: Convert Skyline HAProxy httpcheck https://review.opendev.org/c/openstack/openstack-ansible/+/929892 | 15:46 |
| opendevreview | Jonathan Rosser proposed openstack/openstack-ansible master: Add Ceph test for Rocky Linux https://review.opendev.org/c/openstack/openstack-ansible/+/929636 | 15:47 |
| opendevreview | Jonathan Rosser proposed openstack/ansible-role-uwsgi master: Add libpython definition for ubuntu noble distro install https://review.opendev.org/c/openstack/ansible-role-uwsgi/+/929609 | 15:48 |
| opendevreview | Jonathan Rosser proposed openstack/openstack-ansible-os_keystone master: Ensure that selected Apache MPM is enforced https://review.opendev.org/c/openstack/openstack-ansible-os_keystone/+/929691 | 15:48 |
| opendevreview | Jonathan Rosser proposed openstack/openstack-ansible-os_keystone master: Change example to contain domain name instead of UUID https://review.opendev.org/c/openstack/openstack-ansible-os_keystone/+/919563 | 15:49 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-os_nova master: Allow to apply custom configuration to Nova SSH config https://review.opendev.org/c/openstack/openstack-ansible-os_nova/+/930505 | 19:03 |
| noonedeadpunk | I wonder how we lived without that all this time ^ | 19:03 |
| noonedeadpunk | I would also limit hosts to be frank.... | 19:05 |
| noonedeadpunk | to the mgmt network or smth | 19:05 |
| jrosser | I guess limiting hosts is really an sshd/iptables problem which is not really in scope for OSA to set up? | 20:45 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!