15:04:14 <noonedeadpunk> #startmeeting openstack_ansible_meeting
15:04:16 <openstack> Meeting started Tue Apr 13 15:04:14 2021 UTC and is due to finish in 60 minutes.  The chair is noonedeadpunk. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:04:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:04:19 <openstack> The meeting name has been set to 'openstack_ansible_meeting'
15:04:29 <noonedeadpunk> #topic rollcall
15:04:35 <noonedeadpunk> o/
15:11:17 <noonedeadpunk> #topic bug triage
15:12:37 <noonedeadpunk> https://bugs.launchpad.net/openstack-ansible/+bug/1923183
15:12:37 <openstack> Launchpad bug 1923183 in openstack-ansible "Spice html5 client does not get installed in nova api" [Undecided,New]
15:14:35 <noonedeadpunk> So, it seems that it is distro install
15:14:47 <noonedeadpunk> which fails for centos 8...
15:17:08 <jrosser> hello
15:18:28 <noonedeadpunk> hey! sorry, decided to start meeting with new time today
15:18:39 <noonedeadpunk> probably worth switching from next week....
15:19:54 <jrosser> yeah, just saw my email!
15:21:50 <noonedeadpunk> What do you think about https://bugs.launchpad.net/openstack-ansible/+bug/1923184 ?
15:21:51 <openstack> Launchpad bug 1923184 in openstack-ansible "Allow disable console_agent when using spice console" [Undecided,New]
15:23:13 <noonedeadpunk> sounds pretty fair for me...
15:24:06 <jrosser> a config override can disable that?
15:24:25 <noonedeadpunk> I think it can....
15:24:58 <noonedeadpunk> but probably it really make sense to change default behaviour we have
15:25:28 <jrosser> i'm struggling to find docs for this
15:26:43 <noonedeadpunk> https://docs.openstack.org/nova/victoria/configuration/config.html#spice.agent_enabled
15:27:23 <noonedeadpunk> I think we just misused nova_console_agent_enabled...
15:28:08 <jrosser> yeah that is pretty odd use of it
15:29:29 <jrosser> there is the same oddness in the vnc conditional block too
15:29:38 <noonedeadpunk> Eventually, I'd probably just dropped nova_console_agent_enabled at all...
15:30:30 <noonedeadpunk> and made to use overrides in case agent_enabled should be adjusted
15:31:14 <jrosser> feels like this uses also mis-uses that variable https://github.com/openstack/openstack-ansible-os_nova/blob/master/defaults/main.yml#L212
15:31:37 <jrosser> that'll be disabling [spice|vnc] on aarch64
15:31:44 <jrosser> which is serial only
15:32:18 <noonedeadpunk> hm, yes... I think that we can just set `nova_console_type` to false or smth
15:32:29 <noonedeadpunk> wait...
15:32:47 <noonedeadpunk> https://github.com/openstack/openstack-ansible-os_nova/blob/master/defaults/main.yml#L266
15:33:19 <noonedeadpunk> we're not using it in `[serial_console]`
15:33:32 <noonedeadpunk> Super weird really
15:33:50 <noonedeadpunk> So, we can either fix behaviour, then it would be limited to spice only I guess?
15:33:58 <noonedeadpunk> Or we can jsut drop variable :)
15:36:26 <jrosser> this code is nuts
15:37:15 <jrosser> seems like a legitimate use case to want to disable it for windows
15:38:23 <noonedeadpunk> so you suggest fixing it?
15:38:40 <noonedeadpunk> or we can fix, backport and drop afterwards :p
15:38:43 <jrosser> for spice i think fix
15:39:02 <jrosser> then i have no idea what the point of this is https://github.com/openstack/openstack-ansible-os_nova/blob/master/defaults/main.yml#L224
15:39:14 <jrosser> so drop that, and clean up all the aarch64 logic
15:40:20 <noonedeadpunk> I'm more wondering about that https://github.com/openstack/openstack-ansible-os_nova/blob/master/defaults/main.yml#L212
15:40:53 <jrosser> that looks bogus, and should be just True
15:41:12 <noonedeadpunk> It's just not used anywhere to add
15:41:15 <noonedeadpunk> https://codesearch.opendev.org/?q=nova_spice_console_agent_enabled&i=nope&files=&excludeFiles=&repos=
15:41:38 <jrosser> both spice and vnc should already be disabled for aarch64 from here https://github.com/openstack/openstack-ansible-os_nova/blob/master/defaults/main.yml#L266
15:41:58 <noonedeadpunk> and they are I'm pretty sure, yes
15:42:29 <jrosser> oh well thats actually the bug then, this line https://github.com/openstack/openstack-ansible-os_nova/blob/master/templates/nova.conf.j2#L79
15:42:30 <noonedeadpunk> I'm mrore frustrated is that we have nova_spice_console_agent_enabled, nova_novncproxy_agent_enabled and nova_console_agent_enabled
15:42:42 <jrosser> should be nova_spice_console_agent_enabled
15:42:59 <jrosser> there us no need for nova_console_agent_enabled or nova_novncproxy_agent_enabled that i can see
15:43:20 <jrosser> it's a specific setting for spice?
15:43:21 <noonedeadpunk> yeah
15:43:33 <noonedeadpunk> Well, from what I see from nova config reference
15:44:22 <jrosser> what a mess /o\ my head hurts :)
15:45:17 <noonedeadpunk> well, I'd vote actually for removing all these options, and make use overrides. But porbably nova_spice_console_agent_enabled is really pretty widespread usecase, so maybe worth leaving this single var indeed...
15:45:39 <jrosser> i think thats the best simplification given it's an already existing var
15:45:42 <noonedeadpunk> but yeah, that's a mess and great it has been raised
15:45:47 <openstackgerrit> Merged openstack/openstack-ansible master: Return PyMySQL installation for distro installs  https://review.opendev.org/c/openstack/openstack-ansible/+/784957
15:46:05 <noonedeadpunk> ok, greed then
15:46:11 <noonedeadpunk> *agreed
15:46:16 <noonedeadpunk> #topic office hours
15:46:54 <noonedeadpunk> THe most problematic things at the moment are not being able to merge bump and mariadb version upgrade
15:47:13 <jrosser> yeah, very sad that theres been no further movement on the mariadb jira ticket
15:47:15 <noonedeadpunk> bump fails on rabbitmq ssl, while SSL should not be actually used according to the config...
15:47:40 <jrosser> i wonder if it's worth *downgrading* galera :(
15:47:58 <noonedeadpunk> and I think we'd want to merge it really asap to be able to do freeze for wallaby, and not go forward with master
15:48:33 <jrosser> we'd have to go back to 10.5.7 or something
15:48:36 <noonedeadpunk> and can we technically downgrade to version prior then it was in V?
15:48:58 <jrosser> perhaps, we pin the exact version but the package manager might not like it
15:49:36 <noonedeadpunk> but I mean that mysql_upgrade script might not like it as well...
15:49:51 <jrosser> oh right sure yes, it's just not good really at all
15:50:46 <noonedeadpunk> so I think our best option is kind of to move to admin user somehow, and then we won't care about root missing privileges?
15:50:51 <jrosser> i was thinking should do something really minimal in the PKI role just to get the rabbitmq stuff sorted out
15:50:56 <noonedeadpunk> and I think patch for admin has already merged?
15:51:09 <jrosser> gshippey did a lot of investigation on this
15:52:17 <noonedeadpunk> I will try to sort out bump upgrade tomorrow and also check out on maria after that.
15:52:36 <jrosser> the root user gets broken at upgrade, thats ultimately the issue
15:52:51 <jrosser> it's possible to create a file with some SQL in it which is executed at startup
15:52:53 <noonedeadpunk> Btw for trove, I kind of stopped with internet access from VMs inside aio, as it tries to pull docker image...
15:53:34 <jrosser> that was a possible solution in the maridb jira ticket, to fix the root user permissions at startup with extra params pointing to statements to execute immediately
15:53:42 <noonedeadpunk> but we won't need root user if we create admin somewhere before running setup-infrastructure
15:54:08 <noonedeadpunk> and updating my.cnf
15:54:28 <jrosser> ah, in the upgrade scripts
15:54:37 <noonedeadpunk> (I specificly changed order of tasks lately to prevent my.cnf from being updated before maria upgrade)
15:54:43 <noonedeadpunk> yep
15:55:17 <noonedeadpunk> I think that might work actually
15:55:56 <noonedeadpunk> and root auth with socket I think still working in 10.5.9?
15:56:30 <jrosser> not after the upgrade iirc
15:56:42 <jrosser> as the root user perms get broken
15:56:47 <noonedeadpunk> hm, I thought it affects only password auth?
15:56:58 <noonedeadpunk> but yeah, might be...
15:57:05 <jrosser> the ALL grant goes away
15:57:27 <noonedeadpunk> from all root users or only `root`@`%` or smth?
15:58:06 <noonedeadpunk> as how then non-upgrade tests pass....
15:58:27 <noonedeadpunk> ah, it's broken during running upgrade....
15:58:33 <noonedeadpunk> *mysql upgrade
15:58:42 <noonedeadpunk> damn it....
15:58:54 <noonedeadpunk> maria becomes so buggy lately...
15:59:44 <jrosser> the grants are a bitfield
16:00:00 <jrosser> and the interpretation of the bitfield changes 10.5.8 -> 10.5.9
16:00:07 <noonedeadpunk> oh...........
16:00:18 <jrosser> so what previously meant 'ALL' no longer means 'ALL'
16:00:33 <noonedeadpunk> I read bug report wrong way then....
16:00:40 <jrosser> oh maybe me too :)
16:00:50 <noonedeadpunk> nah, I really just did quick lookthrough
16:01:17 <noonedeadpunk> So it was me under impressions that things are not so bad
16:01:38 <jrosser> it's this massive number "access":18446744073709551615 <- what the bits mean inside that
16:02:39 <jrosser> `And with the addition of the new privilege SLAVE MONITOR, the value has become insufficient for "GRANT ALL":`
16:02:41 <jrosser> doh
16:02:42 <noonedeadpunk> yeah, so then indeed the only option is stratup script, that indeed would fix permissions and got removed afterwards
16:03:11 <noonedeadpunk> but that's so....
16:05:51 <jrosser> i dig around in the code a bit before 8-O https://github.com/MariaDB/server/blob/10.6/mysql-test/main/upgrade_MDEV-19650.test#L20-L53
16:08:04 <noonedeadpunk> I was probably confused with ` IF(JSON_VALUE(Priv, '$.plugin') IN ('mysql_native_password', 'mysql_old_password')`
16:08:16 <jrosser> super fragile here too https://github.com/MariaDB/server/blob/10.6/sql/privilege.h#L72-L78
16:08:47 <noonedeadpunk> doh, indeed... Well, that's C, so everything if fragile...
16:09:01 <noonedeadpunk> I think that's one of the reasons why Rust becomes more and more popular
16:09:12 <jrosser> anyway :)
16:09:19 <noonedeadpunk> #endmeeting