| noonedeadpunk | to be absolutely frank - I wouldn't spend time on fixing functional ones... | 07:50 |
|---|---|---|
| jrosser | yeah i think i changed my mind on this now - i spent most of yesterday on it and just got deeper and deeper into problems in the tests repo | 07:54 |
| noonedeadpunk | we collected depts there for 4 years at least | 07:55 |
| noonedeadpunk | *debts | 07:55 |
| jrosser | so what i wanted to show you was this https://review.opendev.org/c/openstack/openstack-ansible-plugins/+/939957 | 07:55 |
| noonedeadpunk | Yeah, I looked at it once you've pushed and it was extremely neat | 07:56 |
| noonedeadpunk | Was also thinking if smth like that needs to be done with config_template, but then once looked at the module - got unsure about it | 07:57 |
| noonedeadpunk | as we're taking regular `ansible.builtin.template` as a base there iirc | 07:57 |
| jrosser | 939957 is passing the old functional tests on jammy | 07:57 |
| noonedeadpunk | and they fail differently for centos/jammy | 07:58 |
| jrosser | as i've got a depends-on somewhere down the chain to fix some stuff, that shows that all those changes to the ssh plugin are basically ok | 07:58 |
| noonedeadpunk | there're quite some integrated jobs in there | 07:59 |
| jrosser | but really what needs to happen is porting the functional test now to molecule rather than spend more time on the tests repo | 07:59 |
| noonedeadpunk | and iirc plugins works nice in terms of dependency now | 07:59 |
| noonedeadpunk | so yes | 07:59 |
| jrosser | i'm happy enough that i've not broken the ssh plugin with those changes | 07:59 |
| noonedeadpunk | yeah, totally | 07:59 |
| noonedeadpunk | I didn't manage to pull in changes locally though. | 08:00 |
| jrosser | centos molecule is still wierdly broken and will need a held node | 08:00 |
| noonedeadpunk | but I'd expect it either to just work or break badly to be frank | 08:00 |
| jrosser | i'm away for the whole of next week so won't be able to look at this all for a while | 08:01 |
| noonedeadpunk | ++ | 08:01 |
| noonedeadpunk | I can try to check on functional replacements in plugins I guess | 08:02 |
| noonedeadpunk | also with held node would be really nice to test https://review.opendev.org/c/openstack/ansible-role-systemd_mount/+/939303 - as that is weird | 08:02 |
| jrosser | thats quite repeatable isnt it | 08:02 |
| noonedeadpunk | well | 08:02 |
| jrosser | but super oddly, only in the gate job? | 08:03 |
| noonedeadpunk | only in gates? | 08:03 |
| noonedeadpunk | and sometimes rocky, sometimes centos | 08:03 |
| noonedeadpunk | so means it is kinda intermittent | 08:03 |
| noonedeadpunk | I wonder if we can somehow ignore cleanup errors | 08:03 |
| jrosser | we dont really need to destroy the container in CI | 08:04 |
| noonedeadpunk | yeah | 08:04 |
| jrosser | but that kind of feels like cheating when the debuntu ones just work ok | 08:04 |
| noonedeadpunk | it would be nice to fix it though... but overall... | 08:04 |
| jrosser | so if you had any time to look at the plugins repo tests that would be super cool | 08:05 |
| noonedeadpunk | true | 08:05 |
| jrosser | i think all the needed parts are in my patches for plugins and lxc_container_create roles | 08:05 |
| noonedeadpunk | I'll try to have a look next week, sure | 08:07 |
| noonedeadpunk | I was also planning to pick up on rabbitmq and galera clean-ups once we have molecule for them | 08:08 |
| jrosser | its all really good - revealing some hidden bugs too which is kind of the point | 08:09 |
| noonedeadpunk | and extending things there a little bit | 08:09 |
| noonedeadpunk | one annoying thing - is that verify doesn't have role variables, which is annoying | 08:09 |
| noonedeadpunk | I wanted to test installed versions and realized I don't have vars | 08:09 |
| jrosser | i wondered if we could somehow move the log collection script to be somthing in the plugins collection | 08:10 |
| jrosser | openstack.osa.collect_logs <- handwaving | 08:10 |
| jrosser | becasue then we could reuse it in the molecule stuff, and only have a single copy to worry about | 08:10 |
| noonedeadpunk | but our collect logs is kind of basjh script today? | 08:11 |
| jrosser | oh sure yes | 08:11 |
| jrosser | it could be an action plugin quite easily | 08:11 |
| noonedeadpunk | but can we load an action plugin into zuul native executor? | 08:12 |
| noonedeadpunk | as it doesn't supprot collection installation anyway | 08:12 |
| noonedeadpunk | afaik | 08:12 |
| noonedeadpunk | (maybe they've implemented that recently though) | 08:12 |
| jrosser | that was a problem before for sure | 08:13 |
| noonedeadpunk | as we collect logs in post tasks kinda | 08:13 |
| noonedeadpunk | eventually. for molecule - we need to configure molecule to log docker somewhere | 08:13 |
| noonedeadpunk | and then collect these | 08:13 |
| noonedeadpunk | and likely our current implementation can just work, as job is defined in integrated repo | 08:14 |
| jrosser | thats what got me thinking about the existing script | 08:14 |
| jrosser | that it already understands how to reach into lxc's to grab logs | 08:14 |
| jrosser | and perhaps there is an extension to it to make it know how to reach into docker to grab exactly the same things | 08:15 |
| jrosser | we have just switched the container tech, everything else is the same really, systemd, the log locations and things we want etc | 08:16 |
| noonedeadpunk | I assume that logs are even collected somewhere: https://github.com/ansible-community/molecule-plugins/blob/main/src/molecule_plugins/docker/playbooks/create.yml#L159 | 08:16 |
| noonedeadpunk | oh, you mean that.... | 08:16 |
| noonedeadpunk | I think question would be - how much scenarios are we planning to have, outside of connection plugin and 2 lxc roles, to spawn lxc inside docker | 08:17 |
| jrosser | well aside from that, we want the rabbitmq and mariadb logs? | 08:17 |
| jrosser | which right now we cant see from molecule | 08:18 |
| noonedeadpunk | so, if we can get logs from docker natively - that should be fine? | 08:18 |
| jrosser | maybe i miss something, but is that the whole journal for all the services? | 08:19 |
| jrosser | as we kind of abuse docker here by running systemd inside it | 08:19 |
| jrosser | so normally docker log will be the log of the one process you run in the container | 08:19 |
| noonedeadpunk | yeah, you can be right here | 08:20 |
| noonedeadpunk | hm | 08:20 |
| noonedeadpunk | what if we use volume for docker? | 08:21 |
| noonedeadpunk | as iirc our log script can iterate over systemd folders | 08:21 |
| jrosser | perhaps - i'm not sure that the binary format of the journal is portable though | 08:22 |
| jrosser | like noble host parsing centos journal file might not go well | 08:22 |
| noonedeadpunk | ah... | 08:25 |
| noonedeadpunk | depends on systemd version, yes | 08:25 |
| jrosser | well actually this is interesting https://systemd.io/PORTABILITY_AND_STABILITY/ | 08:26 |
| jrosser | the claim there is that the journal file format is part of the stable interface | 08:27 |
| jrosser | so that would be an interesting experiment | 08:27 |
| noonedeadpunk | so bind mount /var/log/systemd into docker... | 08:29 |
| noonedeadpunk | or well, journald, anyway | 08:30 |
| jrosser | hah well even /var/log too | 08:31 |
| jrosser | then the whole existing log collection script would kind of do the right thing, if we give it some alternative path | 08:32 |
| noonedeadpunk | yeah, potentially | 08:40 |
| *** tosky_ is now known as tosky | 08:53 | |
| noonedeadpunk | ok, so now same failure for noble: https://zuul.opendev.org/t/openstack/build/9574015981074ecd88a5003c6cb916a3 | 08:54 |
| noonedeadpunk | for systemd_mount | 08:54 |
| *** tosky is now known as Guest6863 | 13:19 | |
| *** tosky_ is now known as tosky | 13:19 | |
| birbilakos | hello everyone! I would like to extend my br-storage network to be accessible via an openstack network definition to VMs. I'm using OVS. My current definition of this network is as follows: https://paste.opendev.org/show/bVJwIzPmRy4zZq7jIlMK/ | 18:45 |
| birbilakos | would simply adding - neutron_openvswitch_agent to the group binds of this nework do the trick? How would be the provider network type to use then? flat? | 18:46 |
| jrosser | that is an unusual thing to do | 18:50 |
| jrosser | the storage network is privileged and not really intended to be accessed by guests | 18:50 |
| birbilakos | well ,I need to do some NFS sharing over my ceph cluster - which is on the storage network | 18:58 |
| birbilakos | is there some more elegant way? | 18:59 |
| birbilakos | technically I can create a new ext network and veth pair it to the br-storage network and it would work (done it in the past) | 19:00 |
| birbilakos | my question is more in the context of just exposing the br-storage to neutron_openvswitch_agent | 19:01 |
| jrosser | i don;t know tbh | 19:01 |
| birbilakos | I don't care about the security implications really :) | 19:01 |
| jrosser | becasue if you give the storage interface to OVS i'm not sure what the means for the compute host itself accessing the storage | 19:02 |
| jrosser | which is the purpose of the storage networ | 19:02 |
| birbilakos | hmmm how do people normally expose NFS on ceph to their VMS? | 19:04 |
| birbilakos | manilla? | 19:05 |
| jrosser | well there is the manila service, can be complicated though | 19:05 |
| jrosser | or you can mount a volume in a vm and run the nfs server in there | 19:05 |
| jrosser | but it depends what you want really | 19:05 |
| jrosser | i think for what you describe, it's cleaner to access the ceph cluster through the external network | 19:06 |
| jrosser | or you need to do $something on the compute nodes so that there is an interface you can give to ovs on the storage network | 19:07 |
| jrosser | but also one on the host for kvm/rbd | 19:07 |
| jrosser | ^ i've never done any of this tbh so am kind of guessing | 19:07 |
| birbilakos | yeah second approach is what I did in the past | 19:16 |
| birbilakos | https://paste.opendev.org/show/bzsSjS1I7E14pv49YMh0/ | 19:16 |
| birbilakos | and then use 'flat2' as a flat type Physical Network | 19:17 |
| birbilakos | i'll try that again, is the os-neutron playbook enough in this case? | 19:18 |
| jrosser | should be yes | 19:23 |
| jrosser | you should be able to use `--tags neutron_config` to skip all the installation parts | 19:24 |
| birbilakos | will tst this | 19:26 |
| birbilakos | didnt seem to do any changes :( | 19:31 |
| birbilakos | just running the playbook worked. And I'm able to nfs mount via the new neutron network in the VMs :) | 19:55 |
| opendevreview | Merged openstack/openstack-ansible stable/2024.2: Fix inventory adjustment for legacy container naming https://review.opendev.org/c/openstack/openstack-ansible/+/939341 | 22:44 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!