| noonedeadpunk | I kinda wonder, if binding haproxy to an interface might solve the issue? As then you kinda don't care about IPs anymore, just domain | 00:17 |
|---|---|---|
| noonedeadpunk | jrosser: you might be interested in this: https://github.com/rabbitmq/erlang-debian-package/discussions/33 - thanks and kudos to our kolla friends :) | 00:28 |
| anskiy | https://github.com/gnocchixyz/gnocchi/issues/1304 :( | 07:45 |
| noonedeadpunk | we used to maintain setuptools version in global-requirement-pins.txt | 08:57 |
| noonedeadpunk | but we've dropped it once it was added to u-c back in yoga | 08:58 |
| noonedeadpunk | Sounds like we should return it there | 08:58 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible master: Pin version of setuptools https://review.opendev.org/c/openstack/openstack-ansible/+/886731 | 09:04 |
| noonedeadpunk | anskiy1: ^ | 09:04 |
| jrosser | is it still in u-c? | 09:05 |
| noonedeadpunk | nope | 09:06 |
| noonedeadpunk | was dropped after Yoga | 09:06 |
| jrosser | aha | 09:07 |
| anskiy1 | noonedeadpunk: I wonder if pinning it for every venv could break something | 09:26 |
| noonedeadpunk | I would be really surprised if it will | 09:27 |
| jrosser | more likley to stabilise things rather than break | 09:27 |
| noonedeadpunk | but major breaking upgrades for sure can break things retrospectively | 09:27 |
| noonedeadpunk | (upgrades of setuptools) | 09:28 |
| noonedeadpunk | as chances of 2y software to be compatible with brand new setuptools are quite vague | 09:28 |
| noonedeadpunk | as it could be released before they've marked some feature for deprecation | 09:28 |
| anskiy1 | well, it looks like the actual problem is within gnocchi, as it uses pyproject.toml, which, if I understood correctly, uses his `build-system.requires` and installs latest setuptools :( | 11:12 |
| opendevreview | Merged openstack/openstack-ansible-os_cinder master: Use v3 service type in keystone_authtoken config https://review.opendev.org/c/openstack/openstack-ansible-os_cinder/+/886497 | 11:16 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-os_gnocchi master: DNM https://review.opendev.org/c/openstack/openstack-ansible-os_gnocchi/+/886740 | 11:29 |
| opendevreview | Merged openstack/openstack-ansible-os_manila master: Switch jobs to Jammy https://review.opendev.org/c/openstack/openstack-ansible-os_manila/+/884363 | 11:30 |
| noonedeadpunk | I'm also pretty much o_O about https://github.com/rabbitmq/erlang-debian-package/discussions/33 today... | 12:24 |
| noonedeadpunk | Great news that rmq folks published their aarch64 packages somewhere | 12:25 |
| noonedeadpunk | but what happened next made me super confused | 12:25 |
| jrosser | i wonder if the rabbitmq people are fed up with supporting erlang packaging, which kind of isn't their problem? | 12:45 |
| noonedeadpunk | yeah, might be | 12:49 |
| noonedeadpunk | Last time I checked erlang repos they were still broken | 12:49 |
| noonedeadpunk | they don't even have 26.0 being built | 12:51 |
| jrosser | that is all another big mess tbh https://github.com/esl/packages/issues/15 | 12:52 |
| noonedeadpunk | well, at least they seem to have x86_64, not arm64 though :( | 12:57 |
| NeilHanlon | :\ | 13:01 |
| amarao | Is it possible to add one more ssh CA? I'm running around ssh_keypairs role and playbooks/certificate-ssh-authority.yml, but I can't find a way to add a CA without generating it. | 13:20 |
| NeilHanlon | iirc that is setup to do only one ssh CA. What's the use case around multiple CAs? | 13:23 |
| noonedeadpunk | amarao: I think you should be able to do different CAs for different groups? | 13:31 |
| amarao | No, I want to keep original osa machinery intact and I want to add our own CA public key (which we have no private key for at deployment time) for authorizing operators on the servers. | 13:42 |
| amarao | I found clash with TrustedUserCAKeys directive in sshd config (between our code and openstack-ansible), and I'm trying to find middle ground. | 13:43 |
| noonedeadpunk | so /etc/ssh/trusted_ca is assembled from files in /etc/ssh/trusted_ca.d/ ? | 13:45 |
| noonedeadpunk | Meaning, if you add more content there - it will be respected for TrustedUserCAKeys? | 13:45 |
| noonedeadpunk | but I'm not sure | 13:46 |
| jrosser | amarao: we have a setup exactly like what you describe | 13:49 |
| jrosser | if you ensure that a copy of your CA public key is in `/etc/ssh/trusted_ca.d/` then it will be included with the one generated by OSA when the playbooks run | 13:50 |
| jrosser | amarao: is there something i've missed that causes a conflict? | 13:57 |
| amarao | Oh, wait, I misread code. I thought install_ssh_ca.yml wipes out everything which is not in ssh_keypairs_install_ca. It looks like it wipes only entities with state='absent'. Thank you for forcing me to reread it. | 14:00 |
| jrosser | this was designed to be flexible enough to integrate with hosts provisioned by PXEboot with ssh CA config in place after provisioning | 14:01 |
| jrosser | i think we do have a missing feature in the ssh_kepairs role where you may want to supply an existing public key and have that installed but never generated | 14:17 |
| opendevreview | Jonathan Rosser proposed openstack/openstack-ansible-plugins master: Remove special case for Centos 8 https://review.opendev.org/c/openstack/openstack-ansible-plugins/+/886761 | 14:20 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!