15:04:24 <noonedeadpunk> #startmeeting openstack_ansible_meeting 15:04:24 <opendevmeet> Meeting started Tue Feb 4 15:04:24 2025 UTC and is due to finish in 60 minutes. The chair is noonedeadpunk. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:04:24 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:04:24 <opendevmeet> The meeting name has been set to 'openstack_ansible_meeting' 15:04:31 <noonedeadpunk> #topic rollcall 15:04:43 <noonedeadpunk> half-here as on the event right now 15:05:54 <jrosser> o/ hello 15:10:42 <noonedeadpunk> #topic office hours 15:11:02 <noonedeadpunk> so. this weak I realized we're having soooo much things to grow in :D 15:11:08 <noonedeadpunk> *week 15:11:55 <jrosser> i hope you make some notes :) 15:12:23 <noonedeadpunk> Yeah, some. Btw, I was wondering, do you happen to use VSCode or some other IDE? 15:12:37 <jrosser> mostly just vim 15:12:56 <jrosser> but for serious search/replace across all the repos, then yes vscode 15:13:02 <noonedeadpunk> as one thing I learned about - ansible development environment. Basically a way to spwan a docker container with pre-installed ansible-core/molecule/etc 15:13:22 <jrosser> also the ssh remote thing to make a vm appear like local development is excellent 15:13:25 <noonedeadpunk> and then there's a way to spawn workloads from it 15:13:45 <noonedeadpunk> and you can quite easily describe and ship config for vscode to spawn such environment 15:14:45 <noonedeadpunk> pretty much through https://github.com/Microsoft/vscode-remote-release 15:15:06 <noonedeadpunk> sorry, * https://code.visualstudio.com/docs/devcontainers/containers 15:15:55 <noonedeadpunk> but there're quite some ways of doing same without vscode as well 15:16:23 <jrosser> ah yes i am already familiar with https://code.visualstudio.com/docs/remote/ssh 15:16:55 <noonedeadpunk> yeah, I firstly set link to the bundle instead of specific plugin 15:17:40 <noonedeadpunk> so basically if we have devcontainer.json file in tree of roles with molecule - it might make experience sooooo much better 15:18:52 <noonedeadpunk> another thing I learned - is argument spec files for roles 15:18:55 <noonedeadpunk> https://docs.ansible.com/ansible/latest/collections/ansible/builtin/validate_argument_spec_module.html 15:19:18 <noonedeadpunk> where one can describe expected input to the role and then verify it's validity 15:20:02 <noonedeadpunk> so that you can resolve/fail faster 15:20:25 <noonedeadpunk> and then it makes generating documentation for module way more trivial 15:20:48 <jrosser> though if you have the whole external interface in defaults/main.yml...... 15:21:55 <jrosser> it might be more appropriate when we iterate over include_tasks or whatever in openstack service setup, and the input data it complex 15:22:51 <noonedeadpunk> so the thing is, that we know defaults work, but let's say neutron. it's quite frequent one can mis-use mappings... I'm not sure though if it arg spec can prevent this prom happening or not... 15:23:47 <jrosser> yes and the rules for what you have to have in those mappings is super unclear 15:23:52 <noonedeadpunk> just I think in general it might be nice to fail early in some tricky places we aware about... but yeah, probably it's not very important indeed for now 15:24:29 <jrosser> i expect some of the "utility" roles would benefit most, rather than the openstack services to start with 15:24:32 <noonedeadpunk> but then kind if we can define a rule for smth - probably it's worth re-factoring a bit and making more obvious? 15:24:40 <noonedeadpunk> oh, yes, sure 15:25:03 <jrosser> as the inputs tend to be "list of things", defaults to [] 15:26:04 <noonedeadpunk> well, yes, on that level it's not gonna be helpful at all 15:29:01 <noonedeadpunk> but it can be handy at some cases... at least describe allowed or mutually exclusive options we do not support 15:29:21 <noonedeadpunk> but agree - it mostly happens inside of complex data structures in our case 15:29:46 <noonedeadpunk> also - I learned about Conjur today - kinda "vault" alternative: https://github.com/cyberark/conjur 15:30:27 <noonedeadpunk> I think interesting part was, that you kinda register ansible controller once and allow there access to group hosts registered in service 15:31:27 <noonedeadpunk> but also it pushed me to the idea of replacing ssh keys with such secrets 15:31:37 <noonedeadpunk> and probably writing some doc on how to do that 15:31:45 <noonedeadpunk> (even with vault) 15:32:17 <noonedeadpunk> but worse part - is that again it's all just lookups :( 15:32:35 <noonedeadpunk> though you don;'t need to have a token supplied each time you run ansible 15:32:46 <noonedeadpunk> as once host is registered - it can operate and fetch things. 15:33:03 <noonedeadpunk> so kinda sounded neat 15:33:41 <jrosser> so for vault+jenkins we give jenkins a token 15:34:00 <jrosser> and you can do things like make that token only valid for the IP you want 15:34:03 <noonedeadpunk> and you don't run anything manually from the deploy host? 15:34:11 <jrosser> a mixture 15:34:21 <opendevreview> Merged openstack/openstack-ansible master: docs: adjust rabbitmq quorum queue guidance for 2024.2 onwards https://review.opendev.org/c/openstack/openstack-ansible/+/940693 15:34:25 <jrosser> periodic stuff in jenkins "is everything broken?" kind of jobs 15:34:38 <noonedeadpunk> I think what I don't like most right now - is usage of passwordless SSH key 15:34:57 <noonedeadpunk> for the root user, kinda 15:35:11 <noonedeadpunk> at least that's what we "promote" most 15:35:16 <jrosser> signed keys make that ephemeral at least 15:35:59 <jrosser> though we pretty much just leave this to the operator to decide i guess 15:36:28 <noonedeadpunk> true 15:36:44 <noonedeadpunk> but would be nice to have some options documented one day 15:36:58 <jrosser> now we have fixed the connection plugin it would be good to have a "non root" job 15:37:15 <noonedeadpunk> ++ 15:37:37 <jrosser> i expect it is mostly ok, but there will be some errors for sure 15:38:06 <noonedeadpunk> So there were multiple things I've faced when tried last time... 15:38:21 <noonedeadpunk> like owner of the user_secrets 15:38:49 <noonedeadpunk> but for metal it was doable, yes 15:39:20 <noonedeadpunk> still - you kind of assumed to have the user added to sudoers with * more or less 15:39:38 <noonedeadpunk> and passwordless escalation 15:39:41 <jrosser> you do 15:39:51 <jrosser> so this is kind of security theatre imho 15:40:02 <noonedeadpunk> yeah, totally 15:41:23 <opendevreview> Jonathan Rosser proposed openstack/openstack-ansible stable/2024.2: docs: adjust rabbitmq quorum queue guidance for 2024.2 onwards https://review.opendev.org/c/openstack/openstack-ansible/+/940715 15:41:41 <noonedeadpunk> ah, also I was shown a mise - alike to pyenv, except supports more languages https://mise.jdx.dev/environments/ 15:44:23 <jrosser> so i still need to work some more on why molecule is unreliable on the plugins repo 15:44:33 <jrosser> there is something difficult to reproduce happening there 15:44:45 <noonedeadpunk> and again - was highly encouraged to try starting usage of UV instead of PIP for our python_venv_build role. Though I do recall there was smth impossible to do regarding building wheels... But can't recall what, so hard to say if it was fixed or not 15:45:08 <noonedeadpunk> It kind of reliable 15:45:13 <noonedeadpunk> It fails very reliably 15:45:24 <noonedeadpunk> just not reproducible outside of CI 15:46:22 <noonedeadpunk> I think I won't do much this week to be frank, as will be back hopefully Thursday, but likely even Friday 15:46:30 <jrosser> it is strange as the docker connection method has already run things OK 15:46:40 <jrosser> like starting sshd was not successful 15:47:05 <noonedeadpunk> yeah... or it drops connection right after 15:47:50 <jrosser> well actually thats interesting - maybe i should put in a `wait_for` on port 22 15:48:17 <jrosser> nothing really to lose with doing that 15:48:24 <noonedeadpunk> so if tcp runs - it will pass 15:48:27 <noonedeadpunk> yeah, good idea 15:49:46 <noonedeadpunk> it's really confusing why these non-reproducible issues happen only on CentOS 15:50:09 <noonedeadpunk> what so specific could be about CI image influencing that 15:50:37 <noonedeadpunk> which has effect inside docker..,, 15:52:13 <jrosser> and more confusingly its centos container on ubuntu host 15:52:28 <jrosser> so for each of the different OS we test, the parent OS is the same 15:52:35 <noonedeadpunk> well, I tried to run in ubuntu VM 15:53:22 <noonedeadpunk> and, what is even more interesting - it doesn't happen for Rocky 15:53:32 <noonedeadpunk> so it's not some generic ubuntu/el thing 15:53:39 <noonedeadpunk> (at least so far) 15:54:14 <noonedeadpunk> but wait_for is really a good check 15:56:56 <noonedeadpunk> I was also thinking if doing a collection out of all systemd roles would make sense... and make it's releasing independent... 15:57:17 <jrosser> that would be a nice thing 15:58:34 <noonedeadpunk> as eventually one thing I don't know how to solve in a good way -- is release management of collections which are on stable branch policy 15:59:05 <noonedeadpunk> as ideally one need to align tags with versions in galaxy.yml 16:00:26 <noonedeadpunk> but then we can potentially replace chunk of systemd roles with modules 0 like you suggested one day 16:01:35 <noonedeadpunk> also what was tolded - that while roles are not going anyway so far - RH is not gonna invest in future development of tooling to support roles outside of collections 16:01:52 <noonedeadpunk> * told 16:02:22 <noonedeadpunk> #endmeeting