| *** promethe- is now known as prometheanfire | 01:30 | |
| opendevreview | Jimmy McCrory proposed openstack/openstack-ansible master: Add check_hostname option to db healthcheck tasks https://review.opendev.org/c/openstack/openstack-ansible/+/911150 | 02:56 |
|---|---|---|
| noonedeadpunk | jrosser_: yeah, so https://review.opendev.org/c/openstack/openstack-ansible-os_magnum/+/901185 helped indeed: https://review.opendev.org/c/openstack/openstack-ansible-os_magnum/+/901185 | 09:18 |
| noonedeadpunk | * https://review.opendev.org/c/openstack/openstack-ansible/+/911377 | 09:18 |
| noonedeadpunk | also... what a significant difference in runtime between 2023.2 upgrade and 2023.1.... | 09:22 |
| noonedeadpunk | or maybe just not lucky... | 09:22 |
| jrosser_ | noonedeadpunk: do we have a bug to raise for magnum? | 09:55 |
| jrosser_ | for the two images == broken? | 09:55 |
| noonedeadpunk | well. there should be a meaningful exception raised, as they do verify and want to supply ID in such cases. So it might be intended, in a way | 09:56 |
| noonedeadpunk | but yes. there is some bug to raise | 09:56 |
| noonedeadpunk | as first this exception is catched somewhere and way less meaningful thing returned back | 09:56 |
| noonedeadpunk | and then - taking in account deactivated images is also wrong... | 09:57 |
| noonedeadpunk | I will report one shortly | 09:58 |
| jrosser_ | great thankyou | 09:58 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-os_horizon master: Do not change mode of files recursively https://review.opendev.org/c/openstack/openstack-ansible-os_horizon/+/911420 | 10:24 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-os_horizon master: Do not change mode of files recursively https://review.opendev.org/c/openstack/openstack-ansible-os_horizon/+/911420 | 10:25 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-os_horizon master: Detect OVN VPNaaS installation https://review.opendev.org/c/openstack/openstack-ansible-os_horizon/+/911421 | 10:27 |
| g3t1nf0 | jrosser_: my idea and need to run opestack was that I want to offer to my custommers ready k8s clusters that people can hire and test/run in production their applications. | 11:49 |
| g3t1nf0 | is openstack something too heavy for what I need ? should I go the hypervisor way and just start the clusters this way? | 11:50 |
| jrosser_ | you can definatly do that with openstack if you put in some work | 12:07 |
| noonedeadpunk | I think openstack offers quite good amount of tools and features to do that actually | 12:13 |
| noonedeadpunk | not sure if all of them are required if k8s will be the only service in portfolio | 12:14 |
| jrosser_ | noonedeadpunk: should we ask for a unmaintained core group for OSA? | 12:17 |
| g3t1nf0 | I want to go the openstack way because I will be able to do public offering on the openstack as well | 12:17 |
| noonedeadpunk | yes | 12:17 |
| noonedeadpunk | I should propose a patch for that | 12:17 |
| * noonedeadpunk should do plenty of things | 12:18 | |
| frickler | jrosser_: noonedeadpunk: why not join openstack-unmaintained-core? | 12:18 |
| jrosser_ | because i have really nothing to add on things outside osa | 12:18 |
| noonedeadpunk | frickler: I'm not sure we have enough capacity to care about all unmaintained projects | 12:18 |
| jrosser_ | i will bring no value there at all, and have the burden of expectation | 12:19 |
| frickler | you don't have to do that, but you still don't need to add another group | 12:19 |
| noonedeadpunk | and openstack-unmaintained-core not going to care for osa either | 12:19 |
| jrosser_ | this is human factors stuff | 12:19 |
| jrosser_ | and feeling comfortable with what is being taken on | 12:19 |
| jrosser_ | noonedeadpunk: i can make a patch if you like? | 12:22 |
| noonedeadpunk | sure, feel free to | 12:22 |
| jrosser_ | ok will look later, there is an ironic one to reference | 12:23 |
| noonedeadpunk | (and kolla one :D) | 12:24 |
| jrosser_ | g3t1nf0: you should probably look at this for what will become the best approach for openstack/k8s-as-a-service https://github.com/openstack/openstack-ansible-ops/tree/master/mcapi_vexxhost/doc/source | 12:47 |
| jrosser_ | magnum has an existing mechanism that uses openstack heat + lots of bash scripts to deploy k8s | 12:48 |
| jrosser_ | thats not the best thing from an operator perspective, but some do manage to make it work | 12:48 |
| jrosser_ | the future seems to lie with k8s "cluster API" instead | 12:49 |
| jrosser_ | this is all also +/- there being two competing cluster api drivers for magnum, so you should keep an eye on this | 12:49 |
| g3t1nf0 | oh no I don't want to do that I'm gonna install OKD they have installer for openstack | 12:50 |
| g3t1nf0 | the use api calls to provision the whole k8s | 12:50 |
| g3t1nf0 | network storage everything | 12:51 |
| jrosser_ | thats what magnum does | 12:51 |
| jrosser_ | and magnum was on your list of required services yesterday? | 12:51 |
| g3t1nf0 | yeap | 12:51 |
| noonedeadpunk | the bug report for magnum: https://bugs.launchpad.net/magnum/+bug/2056324 | 12:52 |
| g3t1nf0 | keystone, nova, glance, horizon, swift, cinder, neutron, octavia, heat, ceilometer, cloudkitty, trove, magnum, sahara, manila, designate, barbican are the ones that I want | 12:52 |
| g3t1nf0 | from what I've calculated so far I'll have the 3 control planes with 48vcpu and 256G ram and 10 disks then 3 servers with 48vcpus 768G ram and 25 drives for the storage node with 256G ram reservation for ceph and nova, then 3 servers with 48vcpus 768G ram with 25 drives for compute nodes with 128G ram reservation for ceph osds and not sure about the network nodes if I can go just with one or I need another 3 i | 12:57 |
| g3t1nf0 | 256G ram for nova | 12:57 |
| opendevreview | Jonathan Rosser proposed openstack/openstack-ansible-tests stable/zed: Update ansible-core collections to match integrated repo https://review.opendev.org/c/openstack/openstack-ansible-tests/+/911580 | 13:36 |
| opendevreview | Merged openstack/openstack-ansible master: Enable image rotation for Magnum https://review.opendev.org/c/openstack/openstack-ansible/+/911377 | 13:46 |
| opendevreview | Jonathan Rosser proposed openstack/openstack-ansible master: Determine if upgrade source branch is stable/ or unmaintained/ https://review.opendev.org/c/openstack/openstack-ansible/+/911583 | 13:56 |
| *** tosky_ is now known as tosky | 13:57 | |
| opendevreview | Jonathan Rosser proposed openstack/openstack-ansible stable/zed: Determine if upgrade source branch is stable/ or unmaintained/ https://review.opendev.org/c/openstack/openstack-ansible/+/911584 | 14:03 |
| opendevreview | Jonathan Rosser proposed openstack/ansible-role-uwsgi stable/zed: Remove undefined bionic linters job https://review.opendev.org/c/openstack/ansible-role-uwsgi/+/910188 | 14:04 |
| opendevreview | Merged openstack/openstack-ansible-tests stable/zed: Bump ansible-core to 2.12.8 https://review.opendev.org/c/openstack/openstack-ansible-tests/+/911064 | 14:13 |
| opendevreview | Jonathan Rosser proposed openstack/openstack-ansible master: Determine if upgrade source branch is stable/ or unmaintained/ https://review.opendev.org/c/openstack/openstack-ansible/+/911583 | 14:15 |
| opendevreview | Jonathan Rosser proposed openstack/openstack-ansible stable/zed: Determine if upgrade source branch is stable/ or unmaintained/ https://review.opendev.org/c/openstack/openstack-ansible/+/911584 | 14:15 |
| f0o | Hi, I'm trying to setup openstack-ansible with OVN and I'm scratching my head regarding network_interface_mappings values. Specifically I have the issue that my compute nodes have bond0 but my network nodes have mlagXY interfaces. How can I specify different mapping per host or grouping? Or ideally how can I specify a pre-created bridge instead of the physical interface? | 14:22 |
| jrosser_ | f0o: you can find some general info about how to deal with that situation here https://docs.openstack.org/openstack-ansible/latest/user/prod/provnet_groups.html | 14:28 |
| f0o | jrosser_: I followed that but it doesnt seem to play well with OVN as I keep getting the error: "could not add network device br-vlan to ofproto (File exists)" from ovs-vsctl | 14:34 |
| jrosser_ | that documentation will likley predate OVN | 14:34 |
| jrosser_ | but the `group_binds` concept that it is describing will almost certainly be relevant to a config for OVN | 14:35 |
| f0o | unfortunately that seems to be the case with a lot of the docs; a lot of the examples still use linuxbridge too - but OVN is the now default which makes things interesting to setup from the ground up | 14:35 |
| f0o | my biggest issue is that OVN does not like me creating the bridges beforehand (at least that's what I get from the error message) | 14:36 |
| f0o | but I have no clue how else I'm supposed to do this without creating another layer of dummy bridges to get all interface names identical | 14:36 |
| jrosser_ | the names do not have to be identical | 14:36 |
| jrosser_ | you've got two seperable issues | 14:36 |
| jrosser_ | the first is how to describe different provider_networks setups for your different types of host | 14:37 |
| jrosser_ | i beleive that `group_binds` is the way to do that | 14:37 |
| jrosser_ | seperate, is how to specify the interface in a provider_networks section when using OVN | 14:37 |
| f0o | but those sort-of collapse to the same issue. If I can supply a named bridge (br-vlan in this case) to OVN as the backing physical interface then that will be identical for all hosts since I can offload the creation of that named bridge to the OS | 14:39 |
| jrosser_ | but those the ansible will run seperately on those different hosts? | 14:40 |
| f0o | I tried doing that two ways; the first one was to just use openstack_user_config>global_overrides configs like I was used to with linuxbridge - that lead to above error; And then I tried to just user_variables override it and set it as network_interface_mappings - that lead to no erros but no traffic flow either (which I am actually uncertain if it's related or a whole new | 14:41 |
| f0o | error) | 14:41 |
| jrosser_ | did you look at this https://github.com/openstack/openstack-ansible/blob/master/etc/openstack_deploy/openstack_user_config.yml.aio.j2#L178-L192 | 14:41 |
| jrosser_ | the use of "network_interface" specifically | 14:41 |
| f0o | Yep that caused the error I posted | 14:42 |
| f0o | granted I named it br-vlan and not br-provider but the config (other than vlan ranges) is the same | 14:42 |
| f0o | I can retry with br-provider; maybe br-vlan is some reserved name now? | 14:43 |
| noonedeadpunk | So. | 14:43 |
| noonedeadpunk | I'd suggest considering `provider_networks` jsut as a setup for containers | 14:43 |
| noonedeadpunk | and then use neutron_provider_networks for defining mappings for neutron/ovn | 14:44 |
| f0o | noonedeadpunk: while that does make sense, that would mean that I can specify two different values for network_interface_mappings depending if it's compute (bond0) or network/gateway (mlagXYZ) | 14:45 |
| f0o | or get it to work with a bridge-interface which I can freely name the same on all devices | 14:46 |
| jrosser_ | you can define neutron_provider_networks in user_variables to make it global, and you only get to define it once | 14:47 |
| jrosser_ | but if you were to define it in group_vars/<...> you can put it with different values in as many of those as you need | 14:48 |
| noonedeadpunk | neutron_provider_networks make prescedence anyway, so if it's defined - neutron won't care about provider_networks at all | 14:48 |
| noonedeadpunk | Also, I think you can really leverage `group_binds` | 14:48 |
| f0o | jrosser_: what's this magic you speak of, did I entirely miss someway to chuck per-group_binds overrides? | 14:48 |
| noonedeadpunk | But also - there're no containers on net nodes or computes | 14:48 |
| noonedeadpunk | So you need brdiges only on control plane | 14:49 |
| jrosser_ | f0o: what i was trying to tell you earlier about `group_binds` was how you can make parts of provider_networks apply to specific ansible groups | 14:49 |
| f0o | my intial plan was to attempt to get network_mappings: "vlan:br-ext" + network_interface_mappings: "br-ext:br-vlan" to work but I couldnt get any traffic through, mainly I suspected arp_announce being an issue somewhere | 14:49 |
| f0o | jrosser_: apologies for my thickness there | 14:50 |
| jrosser_ | so if you want to, you can essentially duplicate parts of provider_networks, but adjust the interface names | 14:50 |
| jrosser_ | and have them apply *almost* the same config on different hosts, perhaps interfaces being named different | 14:50 |
| jrosser_ | but as noonedeadpunk says you can bypass all of that by using the neutron_provider_networks variable, as an alternative | 14:51 |
| jrosser_ | and if you do that, there are choices about where you define it | 14:51 |
| jrosser_ | /etc/openstack_deploy/user_variables.yml is global and maximum priority (wins over everything else) | 14:52 |
| f0o | I dont mind going neutron_provider_networks route, it does feel more intuitive than provider_networks to be honest. So now I just need to find a way to have ansible differ between two neutron_provider_networks blocks depending on group_binds or host-lists | 14:52 |
| jrosser_ | but the normal rules of ansible variable precedence apply to anything you also define in /etc/openstack_deploy/group_vars/... and /etc/openstack_deploy/host_vars | 14:52 |
| f0o | guess I'll do more digging around | 14:52 |
| f0o | jrosser_: that's a great pointer thanks for clarifying it! | 14:53 |
| jrosser_ | thats ok :) | 14:53 |
| f0o | let me just nuke the rack and have it pxe install some fresh ubuntu -I noticed after re-running ansible a few times the OS gets... tainted | 14:53 |
| f0o | in the meantime I will prepare /etc/openstack_deploy/host_vars for the network nodes | 14:54 |
| jrosser_ | so that would need one file per host | 14:54 |
| jrosser_ | which could be repetitous | 14:54 |
| f0o | this is really a good ansible refresher - last time I used it was years ago | 14:55 |
| f0o | I dont mind repetition here, it'll all just get chucked into git at the end | 14:55 |
| jrosser_ | depending on how you have made your deployment, you can make something like /etc/openstack_deploy/group_vars/neutron_ovn_gateway.yml and put it in there once | 14:55 |
| jrosser_ | though you do have your own choices there about what is / isnt a gateway node | 14:56 |
| noonedeadpunk | and you can also add extra groups if needed | 14:56 |
| noonedeadpunk | this example with AZs might be helpful: https://docs.openstack.org/openstack-ansible/latest/reference/inventory/configure-inventory.html#example-defining-availability-zones | 14:57 |
| noonedeadpunk | and actually, env.d is even slightly optional... | 14:57 |
| jrosser_ | yeah extra group definitions are basically free | 14:57 |
| jrosser_ | and very useful for keeping the variable definitions sane | 14:58 |
| jrosser_ | "compute_with_gpu" or whatever you need | 14:58 |
| f0o | I 100% believe I would've run into this sooner than later | 14:58 |
| f0o | thanks for the link! | 14:59 |
| noonedeadpunk | we have plenty of "hidden" things, unfortunatelly | 14:59 |
| jrosser_ | hmm where did the upgrade jobs on Zed go | 15:01 |
| jrosser_ | like none run here https://zuul.opendev.org/t/openstack/status#911584 | 15:01 |
| f0o | noonedeadpunk:yeah I noticed; I posted a Q on launchpad about that as well. I will collect a bunch of experiences in a document and attempt to update the examples with OVN compatible ones | 15:02 |
| noonedeadpunk | that would be super welcome frankly speaking, as we falling behind need of documentation update | 15:03 |
| f0o | quick Q; do host_vars take precedence over user_variables ? | 15:10 |
| noonedeadpunk | no | 15:10 |
| f0o | ty | 15:11 |
| noonedeadpunk | user_* are passed as extra_vars to asnible, so always have highest prescedence | 15:11 |
| f0o | ok good to know | 15:11 |
| opendevreview | Merged openstack/openstack-ansible-os_glance master: Add property protection configuration https://review.opendev.org/c/openstack/openstack-ansible-os_glance/+/909820 | 15:18 |
| jrosser_ | f0o: there is a useful reference here https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_variables.html#understanding-variable-precedence | 15:25 |
| jrosser_ | openstack-ansible user_variables.yml comes under no.22 there | 15:25 |
| f0o | jrosser_:already on it haha - yeah I wasnt sure where the user_variables are plugged in there since I guess they could've technically be added somewhere 10->18 | 15:27 |
| f0o | but that would also be too late for my use. So now I hope that inference and defaults work | 15:28 |
| f0o | network_interface_mappings: "{{ zz_network_interface_mappings | default('br-ext:bond0') }}" # This is defined in the group/host_vars | 15:28 |
| jrosser_ | openstack-ansible wrapper script converts user_*.yml into as many `-e @/etc/openstack_deploy/user_variables_blah.yml` as you have | 15:29 |
| f0o | have to wait for the reinstall anyway so likely wont get to it today | 15:29 |
| noonedeadpunk | damiandabrowski: can you kindly review this https://review.opendev.org/c/openstack/openstack-ansible-haproxy_server/+/910384 so we could backport and cut a release for 2023.2? | 16:06 |
| noonedeadpunk | this what hit us internally as well fwiw | 16:07 |
| jrosser_ | i still have no clue why https://review.opendev.org/c/openstack/openstack-ansible/+/911584 runs no upgrade jobs | 16:09 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-os_horizon master: Do not change mode of files recursively https://review.opendev.org/c/openstack/openstack-ansible-os_horizon/+/911420 | 16:10 |
| noonedeadpunk | huh | 16:12 |
| noonedeadpunk | feel horizon is completely borked in CI | 16:12 |
| noonedeadpunk | after master sha bump? | 16:13 |
| jrosser_ | i was not able to find a useful log when i quickly looked at that earlier | 16:13 |
| noonedeadpunk | like https://review.opendev.org/c/openstack/openstack-ansible-os_horizon/+/910726 got broken overnight | 16:13 |
| noonedeadpunk | https://zuul.opendev.org/t/openstack/build/4d250f6b56fa46cca6b4b2af8f95923b/log/logs/openstack/aio1_horizon_container-59233b6b/apache2.service.journal-12-36-03.log.txt#4 | 16:13 |
| jrosser_ | /o\ doh there it is :) | 16:14 |
| noonedeadpunk | I guess it's it... But then I have some concerns about django version in u-c.... | 16:14 |
| noonedeadpunk | But I feel it being totally realted to the SHA bump | 16:27 |
| noonedeadpunk | will spawn a sandbox for that... | 16:28 |
| opendevreview | Jonathan Rosser proposed openstack/openstack-ansible stable/zed: Revert "Drop upgrade jobs for Zed" https://review.opendev.org/c/openstack/openstack-ansible/+/911602 | 16:38 |
| jrosser | noonedeadpunk: we should also update the gerrit dashboard to have a unmaintained branches section | 17:07 |
| noonedeadpunk | ugh | 17:08 |
| noonedeadpunk | will do that | 17:08 |
| jrosser | i think i should be able to bring back the Y->Z upgrade jobs | 17:09 |
| noonedeadpunk | I was wondering if that should be done though | 17:09 |
| jrosser | and also fix it so thats more automatic as branch names change in the future | 17:09 |
| noonedeadpunk | as we were dropping them for EM just in case | 17:09 |
| noonedeadpunk | I do agree on the detection patch fully, as such transitions shouldn't block our CI | 17:10 |
| noonedeadpunk | we can actually return Y for now, after bootstrap of Y will be fixed | 17:10 |
| noonedeadpunk | https://bugs.launchpad.net/openstack-ansible/+bug/2055417 | 17:11 |
| jrosser | yeah well thats my motivation really | 17:11 |
| jrosser | last years user survey says most people are on Yoga | 17:13 |
| jrosser | so a route off is needed, which in out case starts usually with the most recent minor upgrade on Y | 17:13 |
| jrosser | even before a major version upgrade | 17:13 |
| jrosser | oh man like all these are just totally missing off the dashboard https://review.opendev.org/q/parentproject:openstack/openstack-ansible+branch:%5Eunmaintained/.*+status:open+ | 17:16 |
| noonedeadpunk | ok, fair enough | 17:17 |
| opendevreview | Jonathan Rosser proposed openstack/openstack-ansible stable/zed: Revert "Drop upgrade jobs for Zed" https://review.opendev.org/c/openstack/openstack-ansible/+/911602 | 17:21 |
| noonedeadpunk | jrosser: about that - maybe it's worth making more/less universal and backport from master? to be ready for Z unmaintained? | 17:33 |
| noonedeadpunk | But I'm looking at https://opendev.org/openstack/openstack-ansible/src/branch/master/scripts/gate-check-commit.sh#L65-L67 now - and on master there's extra complexity present | 17:34 |
| jrosser | which one? | 17:34 |
| jrosser | ah so i did two patches | 17:34 |
| noonedeadpunk | I was looking at https://review.opendev.org/c/openstack/openstack-ansible/+/911584/2/scripts/gate-check-commit.sh#54 | 17:34 |
| jrosser | i also did this https://review.opendev.org/c/openstack/openstack-ansible/+/911583 | 17:35 |
| jrosser | as it was clear it wouldnt backport to Z | 17:35 |
| noonedeadpunk | aha, and now I se efor master | 17:35 |
| jrosser | i gues i should make the change-id be the same, if we eventually backport it to all the branches | 17:36 |
| noonedeadpunk | 1 thing I can think about - some period of time when unmaintained will be created, but stable/ not dropped | 17:36 |
| noonedeadpunk | but this we can probably neglect... | 17:37 |
| jrosser | yeah well it is already a mess with needing to update .gitreview | 17:37 |
| jrosser | but at the same time * else is broken too | 17:38 |
| noonedeadpunk | and naother thing | 17:38 |
| jrosser | so pretty ugly to unbreak it all | 17:38 |
| noonedeadpunk | yeah, so I guess it's fine | 17:38 |
| noonedeadpunk | jsut good to be aware that during some period we can be testing some crap until clean-up will be executed | 17:39 |
| jrosser | so i think my git branch -r | grep blah blah likley breaks if there are two things returned with $branchname in them | 17:40 |
| noonedeadpunk | ah, true as well. add tail -n 1? :) | 17:42 |
| noonedeadpunk | as I guess unmaintained will be lower in the list | 17:42 |
| jrosser | git branch -r | grep origin | sort | grep yoga | tail -n 1 | 17:44 |
| jrosser | perhaps like that | 17:44 |
| g3t1nf0 | so I need just 3 networks vlan 10 20 30 to deploy | 17:58 |
| opendevreview | Merged openstack/openstack-ansible-haproxy_server master: Use correct permissions for haproxy log mount https://review.opendev.org/c/openstack/openstack-ansible-haproxy_server/+/910384 | 18:06 |
| noonedeadpunk | g3t1nf0: um, depends? | 18:16 |
| noonedeadpunk | I guess with the list of services you want - you need way more | 18:16 |
| noonedeadpunk | octavia and trove need their own spearate vlans | 18:16 |
| g3t1nf0 | https://docs.openstack.org/openstack-ansible/2023.2/user/prod/example.html they are missing as a service here but yeah I get what you mean | 18:21 |
| noonedeadpunk | yeah, and our docs also falling behind a bit some prorgress we made... | 18:22 |
| noonedeadpunk | They are relevant for OVS/LXB neutron drivers, but inaccurate for OVN just in case | 18:23 |
| noonedeadpunk | (while OVN being default) | 18:23 |
| g3t1nf0 | I'm looking at ovn yes | 18:23 |
| noonedeadpunk | while generic idea will be same, some configuration will differ a bit | 18:23 |
| noonedeadpunk | but still - you'd need mgmt, tunnel, storage and external connectivity | 18:24 |
| noonedeadpunk | and then lbaas, dbaas... | 18:24 |
| noonedeadpunk | external br-ex can also be a vlan | 18:25 |
| noonedeadpunk | and then you can ignore flat networking | 18:25 |
| g3t1nf0 | for certain it wouldn't be flat networking, I'm just checking the hardening documentation with apparmour | 18:29 |
| g3t1nf0 | why app armour and not selinux if I may ask | 18:29 |
| noonedeadpunk | worth asking deb/canonical I assume... | 18:35 |
| noonedeadpunk | And well. apparmor profiles are distributed with packages | 18:36 |
| noonedeadpunk | and we here mainly don't deal with any EL for quite a while, so no good skill with selinux | 18:36 |
| noonedeadpunk | But any contributions are welcome :) | 18:36 |
| noonedeadpunk | So if you decide to make things working with selinux and redy to make necessary changes - we will be glad to accept them | 18:37 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-haproxy_server stable/2023.2: Use correct permissions for haproxy log mount https://review.opendev.org/c/openstack/openstack-ansible-haproxy_server/+/911603 | 18:38 |
| opendevreview | Merged openstack/ansible-role-systemd_networkd stable/zed: Use OriginalName instead of Name in systemd.link https://review.opendev.org/c/openstack/ansible-role-systemd_networkd/+/908815 | 19:14 |
| jrosser | unmaintained/yoga is now working again https://review.opendev.org/c/openstack/openstack-ansible/+/911621?tab=change-view-tab-header-zuul-results-summary | 21:19 |
| jrosser | and we can bring everything back on zed as well https://review.opendev.org/q/parentproject:openstack/openstack-ansible+branch:%5Estable/zed+status:open+ | 21:20 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!