| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-os_nova stable/2025.2: Ensure nova_console_proxy_types respects all computes https://review.opendev.org/c/openstack/openstack-ansible-os_nova/+/970139 | 08:38 |
|---|---|---|
| opendevreview | Merged openstack/ansible-role-uwsgi master: Update for CONTRIBUTING.rst file https://review.opendev.org/c/openstack/ansible-role-uwsgi/+/969002 | 08:39 |
| opendevreview | Merged openstack/ansible-role-zookeeper master: Update for CONTRIBUTING.rst file https://review.opendev.org/c/openstack/ansible-role-zookeeper/+/962541 | 08:40 |
| opendevreview | Merged openstack/ansible-role-httpd master: Update for CONTRIBUTING.rst file https://review.opendev.org/c/openstack/ansible-role-httpd/+/968960 | 08:46 |
| opendevreview | Merged openstack/ansible-role-pki master: Update for CONTRIBUTING.rst file https://review.opendev.org/c/openstack/ansible-role-pki/+/969003 | 08:47 |
| opendevreview | Merged openstack/ansible-role-frrouting master: Update for CONTRIBUTING.rst file https://review.opendev.org/c/openstack/ansible-role-frrouting/+/969005 | 08:52 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-ansible master: Add AlmaLinux 10 support https://review.opendev.org/c/openstack/openstack-ansible/+/968967 | 08:56 |
| opendevreview | Merged openstack/openstack-ansible master: docs: utility host replace to environment https://review.opendev.org/c/openstack/openstack-ansible/+/970034 | 09:03 |
| opendevreview | Merged openstack/ansible-role-systemd_networkd master: Remove unused directory https://review.opendev.org/c/openstack/ansible-role-systemd_networkd/+/969269 | 10:11 |
| opendevreview | Merged openstack/openstack-ansible-os_ironic stable/2025.2: Remove EL9 compatability https://review.opendev.org/c/openstack/openstack-ansible-os_ironic/+/969892 | 10:43 |
| opendevreview | Merged openstack/openstack-ansible-os_ironic master: Remove outdate file local_install.sh https://review.opendev.org/c/openstack/openstack-ansible-os_ironic/+/959652 | 10:43 |
| opendevreview | Merged openstack/openstack-ansible-rabbitmq_server stable/2025.2: Make jobs voting again https://review.opendev.org/c/openstack/openstack-ansible-rabbitmq_server/+/970127 | 10:49 |
| opendevreview | Merged openstack/openstack-ansible-openstack_hosts master: Remove outdated configure for yum https://review.opendev.org/c/openstack/openstack-ansible-openstack_hosts/+/970169 | 10:50 |
| harun | Hello everyone, I am experiencing an issue related to certificate renewal in Magnum clusters. I have clusters running on the Magnum Cluster API, and the certificate of the cloud URL has changed. As a result, the clusters are now receiving TLS certificate errors when trying to access the cloud URL. | 10:51 |
| harun | From what I observed, the issue is resolved when I manually replace the /etc/kubernetes/cloud_ca.crt file on both the worker and master nodes with the updated certificate. However, is there an easier or more automated way to handle this? | 10:51 |
| opendevreview | Merged openstack/openstack-ansible-os_ironic master: Remove outdate file manual-test.rc https://review.opendev.org/c/openstack/openstack-ansible-os_ironic/+/959648 | 10:51 |
| opendevreview | Merged openstack/openstack-ansible-os_ironic master: Remove deprecated run_tests/vagrantfile https://review.opendev.org/c/openstack/openstack-ansible-os_ironic/+/959649 | 10:51 |
| opendevreview | Merged openstack/openstack-ansible-os_ironic master: Fixes for text formulations (OpenStack, Bare metal) https://review.opendev.org/c/openstack/openstack-ansible-os_ironic/+/969825 | 10:51 |
| noonedeadpunk | hm. I frankly have no idea.... | 10:54 |
| noonedeadpunk | harun: have you tried `openstack coe ca rotate` command? | 10:54 |
| noonedeadpunk | I have no idea if that actually works with capi drivers or not... | 10:55 |
| opendevreview | Merged openstack/ansible-role-systemd_networkd stable/2025.1: Restart systemd-udev on link changes https://review.opendev.org/c/openstack/ansible-role-systemd_networkd/+/970148 | 11:03 |
| jrosser | harun: do you mean that the certificate of your openstack API has changed, or the certificate of the cluster api control plane k8s cluster has changed? | 11:33 |
| harun | jrosser, I mean that the certificate of the OpenStack API has changed. Because of this change, the clusters are now getting TLS errors when they try to access the OpenStack API. | 11:36 |
| opendevreview | Merged openstack/openstack-ansible stable/2025.2: Set Debian 13 molecule test to voting https://review.opendev.org/c/openstack/openstack-ansible/+/970126 | 11:41 |
| opendevreview | Merged openstack/openstack-ansible master: [doc] Add warning about verifying latest stable release tag https://review.opendev.org/c/openstack/openstack-ansible/+/970072 | 11:41 |
| opendevreview | Merged openstack/openstack-ansible master: [doc] Domain routing order warning https://review.opendev.org/c/openstack/openstack-ansible/+/970033 | 11:41 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-ansible master: Move deploy-guide under docs for translation https://review.opendev.org/c/openstack/openstack-ansible/+/949497 | 11:46 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-ansible master: Move deploy-guide under docs for translation https://review.opendev.org/c/openstack/openstack-ansible/+/949497 | 11:46 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-ansible master: Move deploy-guide under docs for translation https://review.opendev.org/c/openstack/openstack-ansible/+/949497 | 11:46 |
| harun | I updated the caCert field in the cluster object using kubectl edit, and new nodes are now created with the updated CA. However, do I need to delete all existing worker nodes and recreate them for the change to take effect? | 11:52 |
| harun | cloudCaCert* | 11:52 |
| jrosser | harun: it is a bit like you need to do a rolling upgrade of the workload clusters, but don't want to change version | 12:02 |
| harun | Yes, exactly. I want to trigger something similar to a rolling upgrade so that all nodes pick up the new CA, but without changing the Kubernetes version. My goal is just to refresh the nodes so they regenerate with the updated certificate, without performing a full version upgrade. | 12:05 |
| jrosser | i think that you can just delete the instances one by one (not for non-ha k8s control plane though) and they will get reprovisioned once capi notices that there are not enough | 12:08 |
| jrosser | that can be pretty tedious though if you have a lot of clusters | 12:08 |
| jrosser | mnaser: do you know if there is a trick to rolling replace the workload clusters without doing an actual upgrade? | 12:09 |
| opendevreview | Dmitriy Chubinidze proposed openstack/openstack-ansible master: [doc] Add correction about latest tag https://review.opendev.org/c/openstack/openstack-ansible/+/970239 | 12:20 |
| opendevreview | Dmitriy Chubinidze proposed openstack/openstack-ansible master: [doc] Add correction about latest tag https://review.opendev.org/c/openstack/openstack-ansible/+/970239 | 12:28 |
| mnasiadka | noonedeadpunk: do you know if anything is happening with the openvswitch collection? | 13:00 |
| noonedeadpunk | I was kinda wondering about it, but failed to follow up due to internal mess... | 13:00 |
| noonedeadpunk | I was not given permissions to it | 13:01 |
| noonedeadpunk | or well... let me double check... | 13:02 |
| noonedeadpunk | nah... | 13:03 |
| noonedeadpunk | pinged gundalow... | 13:03 |
| opendevreview | Dmitriy Chubinidze proposed openstack/openstack-ansible master: [doc] Add correction about latest tag https://review.opendev.org/c/openstack/openstack-ansible/+/970239 | 14:21 |
| noonedeadpunk | if any core is available - would be nice to land these backports: https://review.opendev.org/q/parentproject:openstack/openstack-ansible+branch:%5Estable/2025.2+status:open+ | 14:50 |
| noonedeadpunk | and I'll update/rebase RC2 on top of these | 14:50 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-ansible master: [doc] Add correction about latest tag https://review.opendev.org/c/openstack/openstack-ansible/+/970239 | 14:50 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-ansible master: [doc] Add correction about latest tag https://review.opendev.org/c/openstack/openstack-ansible/+/970239 | 14:51 |
| jrosser | argh /o\ didnt look closely enough at the depends-on :( | 14:55 |
| noonedeadpunk | #startmeeting openstack_ansible_meeting | 15:02 |
| opendevmeet | Meeting started Tue Dec 9 15:02:45 2025 UTC and is due to finish in 60 minutes. The chair is noonedeadpunk. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:02 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:02 |
| opendevmeet | The meeting name has been set to 'openstack_ansible_meeting' | 15:02 |
| noonedeadpunk | #topic rollcall | 15:02 |
| noonedeadpunk | o/ | 15:04 |
| jrosser | o/ hello | 15:04 |
| NeilHanlon | o/ | 15:05 |
| noonedeadpunk | #topic office hours | 15:09 |
| noonedeadpunk | last week we got finally branched 2025.2 | 15:09 |
| noonedeadpunk | and now we're a week in delay with flamingo release | 15:09 |
| noonedeadpunk | Huge cohntributing factor to the delay was rotation of rabbitmq repos, which we missed | 15:10 |
| noonedeadpunk | and learned about once it has happened :( | 15:10 |
| jrosser | were we late to move to an updated version? | 15:10 |
| noonedeadpunk | I think they've announced about removal of ppa1 in advance | 15:13 |
| noonedeadpunk | but I missed that completely | 15:13 |
| noonedeadpunk | anyway, we have what we have, and hopefully backports will land today | 15:13 |
| noonedeadpunk | then we will be able to produce rc2 tomorrow... | 15:14 |
| noonedeadpunk | I have also proposed a patch to start tracking master again: https://review.opendev.org/c/openstack/openstack-ansible/+/970128 | 15:14 |
| noonedeadpunk | and there is one for EOM-ing 2024.1: https://review.opendev.org/c/openstack/openstack-ansible/+/966174 | 15:15 |
| noonedeadpunk | once we're done with release, I'd love to check in PKI patches again, and merge them early in the cycle | 15:15 |
| jrosser | we also need to look at what we are happy with for the magnum patches | 15:16 |
| jrosser | as those are now working functionally | 15:16 |
| jrosser | just we might want to adjust the structure somewhat, or have a plan for what to do with it generally in the next release | 15:16 |
| noonedeadpunk | ++ | 15:18 |
| noonedeadpunk | yes, totally | 15:18 |
| noonedeadpunk | I was just looking today at some of them, and was wondering if we wanna keep the collection named as a specific driver for instance | 15:19 |
| noonedeadpunk | ie: https://review.opendev.org/c/openstack/openstack-ansible/+/966666/11/ansible-collection-requirements.yml | 15:21 |
| noonedeadpunk | so question is - what we wanna do with this collection? | 15:21 |
| noonedeadpunk | rename it in place? | 15:21 |
| noonedeadpunk | or make a new repo for it? | 15:22 |
| noonedeadpunk | or move to plugins? | 15:23 |
| NeilHanlon | i vote for whatever is less work | 15:23 |
| noonedeadpunk | less work is to ignore `vexxhost` in it's naming :D | 15:23 |
| jrosser | ultimately it is a confusion of two things | 15:24 |
| jrosser | there is the control plane k8s deployment | 15:24 |
| noonedeadpunk | ideally - I think, this content would better fit the collection where we deploy k8s from | 15:24 |
| jrosser | and then laying over the top of that whichever capi driver and its accessories that are needed | 15:25 |
| jrosser | (or indeed both of them) | 15:25 |
| noonedeadpunk | so iirc, the only difference between them are namespaces and different set of helm charts... | 15:25 |
| noonedeadpunk | so 2 roles - proxy and sonobuoy are kinda indeed on the top | 15:26 |
| noonedeadpunk | I'm just not sure it's worth to have different colletions on top based of the driver? | 15:27 |
| jrosser | maybe it just needs a capi collection | 15:28 |
| noonedeadpunk | ie CAPI_XXX - collection XXX, CAPI_YYY - collection YYY | 15:28 |
| jrosser | which can have all the bits for both | 15:28 |
| noonedeadpunk | yeah.... | 15:28 |
| noonedeadpunk | I need to get some time to finally get working magnum sandbox deployment... | 15:30 |
| jrosser | andrew has had this all running in AIO fairly straightforwardly | 15:31 |
| jrosser | we are just a bit stuck now to take it beyond our staging environment until the code is in a mergable form | 15:31 |
| jrosser | too much tech debt if we deploy it first tbh | 15:31 |
| noonedeadpunk | ok, so we can land things as is, with commitment to refactor until the next release? | 15:32 |
| jrosser | well i don't know really - like you say it is best to merge it once and right perhaps | 15:33 |
| noonedeadpunk | also - this mcapi_vexxhost.rust role should be just a path in os_magnum, imo | 15:34 |
| noonedeadpunk | it really doesn;t do much except doing apt install... | 15:34 |
| jrosser | path? | 15:34 |
| noonedeadpunk | well, include_tasks: magnum_vexxhost_driver.yml when: magnum_capi_driver == 'vexxhost' | 15:35 |
| noonedeadpunk | or smth like that | 15:35 |
| noonedeadpunk | inside of the os_magnum role? | 15:40 |
| jrosser | right - well atm there is no integration of capi stuff in there at all, which i suppose is the thing we need to think about a bit | 15:41 |
| noonedeadpunk | yes, true | 15:46 |
| noonedeadpunk | I'm not sure, but be guessing that heat driver may vanish anytime now | 15:46 |
| jrosser | currently there is many layers of stuff exactly to keep it separate | 15:46 |
| noonedeadpunk | so it's also not that we had much choice, unless leaving jsut a noop one... | 15:46 |
| noonedeadpunk | we can keep it separate just to have it said, if we want to | 15:47 |
| noonedeadpunk | but probably it might be easier to merge, given we get compatability for both of them | 15:47 |
| noonedeadpunk | and add some check to ensure operator has defined a driver (when heat is removed) | 15:48 |
| jrosser | this sounds like it is a bigger discussion | 15:48 |
| jrosser | maybe we can make an etherpad in a future meeting and try to tie down where all the different parts should live | 15:48 |
| andrewbonney | ^ sounds good to me - I was concerned about having time for a full refactor right now with other priorities, but before next release sounds manageable | 15:52 |
| noonedeadpunk | ++ | 15:55 |
| noonedeadpunk | works for me as well. | 15:55 |
| noonedeadpunk | should we use this link? | 15:55 |
| noonedeadpunk | #link https://etherpad.opendev.org/p/osa-magnum-capi-refactoring | 15:55 |
| noonedeadpunk | #endmeeting | 16:01 |
| opendevmeet | Meeting ended Tue Dec 9 16:01:29 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:01 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/openstack_ansible_meeting/2025/openstack_ansible_meeting.2025-12-09-15.02.html | 16:01 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/openstack_ansible_meeting/2025/openstack_ansible_meeting.2025-12-09-15.02.txt | 16:01 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/openstack_ansible_meeting/2025/openstack_ansible_meeting.2025-12-09-15.02.log.html | 16:01 |
| opendevreview | Merged openstack/openstack-ansible stable/2025.2: Don't use nova_console_type for mapping https://review.opendev.org/c/openstack/openstack-ansible/+/970125 | 16:28 |
| opendevreview | Merged openstack/ansible-role-systemd_networkd stable/2025.2: Restart systemd-udev on link changes https://review.opendev.org/c/openstack/ansible-role-systemd_networkd/+/970147 | 16:29 |
| drarvese | Hello, I'm setting up a OSA 2025.1 multi-node OVN setup on 3 compute nodes in a collapsed compute/gateway setup and I'm having issues with VMs passing network traffic. | 16:49 |
| drarvese | Here's the network interface config of one of the hosts: https://paste.openstack.org/show/bubNMksizOd658nBovzB/ and the relevant provider_network definitions: https://paste.openstack.org/show/bCmTytvjLxgCyID1mRVF/ | 16:49 |
| drarvese | The switch ports that the eno12409np1 interfaces are connected to are tagged VLAN 134 and I can ping the br-vxlan IPs on the other hosts from that interface. VLAN 134 is also the VLAN that our instances will be on. | 16:49 |
| drarvese | OVN seems to be working correctly as far as I can tell. I've created a VLAN provider network and can launch an instance, and see the port in the OVN DB. However, I'm unable to ping anything from the VMs I launch. I can't ping the gateway or other VMs. The only thing I can ping is the "network:distributed" port. | 16:49 |
| drarvese | One of our network engineers thought that we might be double tagging. I'm basically following the production environment example and putting the tunnel network on a VLAN subinterface. | 16:50 |
| drarvese | I'm at a loss as to what the issue is. Does anyone have ideas? | 16:50 |
| drarvese | I just noticed that line 14 in the first paste has "id: 10" for the VLAN ID. That's a typo, it is 134. | 16:52 |
| noonedeadpunk | hey | 17:02 |
| noonedeadpunk | drarvese: give me a sec to read back :) | 17:03 |
| noonedeadpunk | there is totally smth I don't like in the paste.... | 17:08 |
| noonedeadpunk | so on the compute node, can you check the output of `ovs-vsctl list-ports br-vlan` ? Is eno12409np1 part of the bridge? | 17:10 |
| noonedeadpunk | and then also what you have in /etc/neutron/plugins/ml2/ml2_conf.ini as network_vlan_ranges ? | 17:11 |
| noonedeadpunk | (and also type_drivers) | 17:11 |
| drarvese | Yeah, eno12409np1 is on the bridge | 17:11 |
| drarvese | network_vlan_ranges = provider:1:4094 | 17:11 |
| drarvese | type_drivers = vlan,vxlan,local,geneve,flat | 17:12 |
| noonedeadpunk | hm. you should not be having vxlan in there.... | 17:12 |
| noonedeadpunk | how you defined network* in openstack_user_config? | 17:12 |
| noonedeadpunk | trying to ensure that groups are defined correctly for ovn, and do not have ovs/lxb bits | 17:13 |
| drarvese | neutron_plugin_type: ml2.ovn | 17:13 |
| drarvese | neutron_plugin_base: - ovn-router | 17:13 |
| drarvese | neutron_ml2_drivers_type: "vlan,vxlan,local,geneve,flat" | 17:13 |
| noonedeadpunk | aha, ok, so you defined that explicitly? | 17:14 |
| drarvese | Yeah, wasn't sure if it was needed | 17:14 |
| noonedeadpunk | probably explicit is better then implicit?:) | 17:14 |
| noonedeadpunk | But I'd suggest just having neutron_ml2_drivers_type: "vlan,geneve" for your setup | 17:15 |
| noonedeadpunk | and drop type: "flat" from provider_networks | 17:15 |
| noonedeadpunk | I don't think it's configured to be usable right now anyway | 17:15 |
| noonedeadpunk | but also I'm not really sure about vlan134 | 17:16 |
| noonedeadpunk | as it seems to attempt to re-use the vlan id on the interface which is managed by ovs | 17:17 |
| noonedeadpunk | are you able to ping actually nodes via network on br-vxlan? | 17:18 |
| drarvese | I'm able to ping the br-vxlan IPs on the other compute nodes (172.21.4.2, .3) | 17:19 |
| noonedeadpunk | oh, ok, right, as it's vlan interface. right | 17:20 |
| drarvese | Should that bridge be on a separate VLAN so 134 can be used by OVS? | 17:20 |
| noonedeadpunk | nah, not really, but yo udefined range: "1:4094" which might intersect. but as long as you don't create vlan 134 in neutron it should be fine... | 17:21 |
| drarvese | I am creating it in neutron, so maybe that's the problem? | 17:22 |
| noonedeadpunk | em | 17:23 |
| noonedeadpunk | ok, so let me elaborate probably on my expectations from the config I see :) | 17:24 |
| noonedeadpunk | container_bridge: "br-mgmt" - this is the management network, all services are communication with each other. It's defined so that it was passed to all lxc containers and that host_vars were set accordingly | 17:25 |
| noonedeadpunk | container_bridge: "br-vxlan" / type: "geneve" - this network is designed to provide a geneve networks - basically internal networks inside of the openstack, which will be built on top of an interface - vlan134 in your case. It should not be a bridge per say, as encapsulated traffic will be flowing over it | 17:27 |
| noonedeadpunk | so it needs to have an IP address and be reachable | 17:27 |
| noonedeadpunk | container_bridge: "br-vlan" / type: "vlan" - these for actuall tagged VLANs, which are created and managed inside of the Neutron. This is usually used for external networks/connectivity | 17:28 |
| noonedeadpunk | while it's usually not that convenient to use vlans for intenrnal networks for projects, due to limit of 4096 vlans, and requirement to pass vlan tags on network equipment. | 17:29 |
| noonedeadpunk | But you totally can not have vlan to be configured both on OS level and Neutron level | 17:30 |
| noonedeadpunk | Usually, tenants are not even allowed to create a new networks with type vlan in neutron | 17:31 |
| drarvese | This is a relatively small cloud we're creating for our own use, all VMs are going to be on vlan134 | 17:32 |
| noonedeadpunk | and it's an admin-only possibility, while tenants can create geneve networks and as many as they want | 17:32 |
| noonedeadpunk | aha, okay | 17:32 |
| noonedeadpunk | well. If *all* VMs are going to be on the same vlan - maybe you should define it as a flat network? | 17:32 |
| noonedeadpunk | and then you can skip both vlan and geneve ones... | 17:33 |
| noonedeadpunk | you probably should be fine with just this: https://paste.openstack.org/show/b16yWJx64ChFVJZmFtIW/ | 17:34 |
| noonedeadpunk | oops | 17:34 |
| noonedeadpunk | sorry. now | 17:34 |
| drarvese | Well, all VMs right now. That might change in the future. We've used VLAN provider networks everywhere else | 17:34 |
| noonedeadpunk | https://paste.openstack.org/show/b6QxUg2THZsrOSKL0pUj/ | 17:35 |
| noonedeadpunk | and then you don't need to have br-vxlan bridge | 17:35 |
| noonedeadpunk | (in netplan) | 17:36 |
| noonedeadpunk | nor IP address on it | 17:36 |
| noonedeadpunk | if you wanna have vlan networks only - you can also do that | 17:36 |
| noonedeadpunk | but still what you configure on OS level in netplan should not intersect with range property for Neutron | 17:37 |
| noonedeadpunk | You can also add more flat networks to neutron, where each flat network can be a vlan configured in netplan | 17:38 |
| noonedeadpunk | pretty much the difference between flat network and vlan network, is that in vcase of flat you configure interface in OS, and in vlan you oflfoad this to SDN | 17:38 |
| noonedeadpunk | so to add flat network except of os configuration, you will also need to run a playbook | 17:39 |
| noonedeadpunk | and for vlan is just an API call | 17:39 |
| drarvese | Yeah, we want to do vlan, so it sounds like the issue is the OS/neutron intersection | 17:40 |
| noonedeadpunk | yeah | 17:46 |
| noonedeadpunk | I'm pretty sure you can't do like that | 17:47 |
| noonedeadpunk | as also these networks are designed for quite different purposes | 17:47 |
| noonedeadpunk | so current setup assumes that you will be serving geneve netowkrs over vlan134as well | 17:47 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-rabbitmq_server master: Do not run remove_classic_queue_mirroring for distro-isntalled RabbitMQ https://review.opendev.org/c/openstack/openstack-ansible-rabbitmq_server/+/970292 | 17:55 |
| opendevreview | Merged openstack/openstack-ansible-os_nova stable/2025.2: Ensure nova_console_proxy_types respects all computes https://review.opendev.org/c/openstack/openstack-ansible-os_nova/+/970139 | 18:34 |
| opendevreview | Dmitriy Chubinidze proposed openstack/openstack-ansible master: [doc] Add correction about latest tag https://review.opendev.org/c/openstack/openstack-ansible/+/970239 | 18:37 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-ansible master: [doc] Add correction about latest tag https://review.opendev.org/c/openstack/openstack-ansible/+/970239 | 21:38 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-ansible master: [doc] Add correction about latest tag https://review.opendev.org/c/openstack/openstack-ansible/+/970239 | 21:38 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-ansible master: [doc] Add correction about latest tag https://review.opendev.org/c/openstack/openstack-ansible/+/970239 | 21:40 |
| opendevreview | Dmitriy Chubinidze proposed openstack/openstack-ansible master: [doc] Add git fetch step to minor upgrade instructions https://review.opendev.org/c/openstack/openstack-ansible/+/970313 | 21:52 |
| opendevreview | Dmitriy Chubinidze proposed openstack/openstack-ansible master: [doc] Add git fetch step to minor upgrade instructions https://review.opendev.org/c/openstack/openstack-ansible/+/970313 | 21:56 |
| opendevreview | Dmitriy Chubinidze proposed openstack/openstack-ansible-haproxy_server master: Add certbot package variable for RHEL based systems. https://review.opendev.org/c/openstack/openstack-ansible-haproxy_server/+/967195 | 23:29 |
| opendevreview | Dmitriy Chubinidze proposed openstack/openstack-ansible-haproxy_server master: Add certbot package variable for RHEL based systems. https://review.opendev.org/c/openstack/openstack-ansible-haproxy_server/+/967195 | 23:30 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!