[10:01] <hrw> morning
[10:02] <hrw> openstack-dashboard package from Yoga UCA cannot be installed: https://f84c98a8f226742614f6-3aae15598e3520aeb88f6be5e3be9239.ssl.cf5.rackcdn.com/826488/2/check/kolla-build-ubuntu-binary/2736789/kolla/build/000_FAILED_horizon.log
[10:02] <hrw> is it known issue?
[10:06] <hrw> if I install only 'openstack-dashboard' then it installs fine. but adding horizon plugins (like python3-octavia-dashboard) make it fail similar way
[11:07] <hrw> ValueError: Unknown remainder ['+git2021120912', '07e5607'] in '5.0.0+git2021120912.07e5607'
[11:07] <hrw> all over the place
[11:07] <hrw> maybe use '-' between gitDATE and GITREV?
[13:29] <coreycb> hrw: I'll take a look, thanks
[13:30] <athos> /28
[13:54] <ahasenack> cpaelzer: looking for qemu/libvirt/ipxe reviewers still?
[13:55] <ahasenack> I can grab one if no-one has manifested interest yet, any preference on which one to start with?
[13:57] <coreycb> hrw: bug 1959402 - thanks for reporting that, I'll get it fixed up
[14:03] <hrw> coreycb: thanks
[14:05] <ahasenack> kanashiro: in the HA scripts/packaging, are you aware of any setup involving NFS in HA?
[14:30] <kanashiro> ahasenack, AFAICT no
[14:31] <ahasenack> kanashiro: I ask because in the new upstream, /etc/default/nfs-* are ignored
[14:31] <kanashiro> there might be some agent related to NFS but I'd need to check
[14:31] <ahasenack> there is a new config, /etc/nfs.conf
[14:31] <ahasenack> can you do a quick grep, see if something refers to the /etc/default/{nfs-common,nfs-kernel-server} files?
[14:31] <kanashiro> yep, give me a sec
[14:35] <kanashiro> ahasenack, I see some references to /etc/sysconfig/nfs but nothing in /etc/default
[14:41] <ahasenack> ugh, that's even worse then
[14:41] <ahasenack>  /etc/sysconfig/nfs is from redhat/fedora
[14:46] <kanashiro> there are some agents that are supposed to work only in redhat, so this can be one of them
[14:47] <patdk-lap> what HA system are you attempting to use?
[14:47] <kanashiro> patdk-lap, ahasenack is updating nfs-utils and we are checking if the new changes will impact the resource/fence agents we have
[14:48] <ahasenack> that ^
[14:48] <ahasenack> I'm not familiar with HA NFS
[14:48] <ahasenack> but I can see external packages/systems relying on the old config files (/etc/default/nfs-*)
[14:48] <ahasenack> that being said, our nfs package is old
[14:49] <ahasenack> so maybe the HA stuff is actually expecting the new config /etc/nfs.conf already :)
[14:49] <ahasenack> kanashiro: there's a thought, grep for /etc/nfs\.conf too please
[14:49] <patdk-lap> ya, I was going be doing nfs ha soonish
[14:49] <patdk-lap> mostly stuck to iscsi/drbd/zfs/lxc currently
[14:49] <kanashiro> ahasenack, nothing
[14:50] <ahasenack> I did test exporting an iscsi mount via nfs, and rebooting, that worked :)
[14:51] <ahasenack> i.e., no boot ordering issues
[14:51] <kanashiro> ahasenack, I'll be working on the HA packages in February, I'll keep this in mind and see if I can spot something
[14:52] <kanashiro> beginning of February 
[14:52] <ahasenack> if you spot it should support nfs ha, let me know, I can work on that aspect I guess
[14:52] <ahasenack> or help at elast
[14:52] <ahasenack> since nfs has dozens of services :/
[14:53] <patdk-lap> would think most people would have ditched nfs 3 by now
[14:53] <kanashiro> at the moment no nfs related agent is in main, so the others are not fully supported
[14:53] <ahasenack> you actually have to specify you want v3 in the mount options
[14:53] <ahasenack> or else you get v4
[14:53] <kanashiro> but I do not want to break anything :)
[14:53] <ahasenack> I think people think that if they use nfsv4, they have to setup kerberos
[14:53] <ahasenack> I was one of those some years ago :)
[14:54] <patdk-lap> I tried without kerberos or other option, like 8yers ago, it just wouldn't work for me
[14:54] <patdk-lap> I just stopped attempting nfs v4
[14:54] <patdk-lap> but I guess support in the kernel got better, cause I had no issues and moved everything over this year
[14:54] <ahasenack> and, well, our package is very old
[14:54] <ahasenack> it's code from 2015-2016 or so
[14:55] <patdk-lap> well, i know 12.04 didn't work well with v4 in sys mode for me
[14:55] <ahasenack> I noticed some changes in how nfsv4 tracks rebooted clients, for starters
[14:55] <ahasenack> there is a new daemon for that
[14:55] <patdk-lap> 20.04 works just fine :)
[14:55] <ahasenack> 12.04, what was that, precise?
[14:55] <patdk-lap> ya
[14:56] <patdk-lap> I don't remember if I tested it explicity in 14.04
[14:56] <patdk-lap> and I mostly skipped 16.04 and 18.04
[14:56] <ahasenack> I'm building the upcoming jammy packages in this ppa: https://launchpad.net/~ahasenack/+archive/ubuntu/nfs-utils-merge
[14:57] <ahasenack> the upgrade path is a bit broken, in the sense that options from /etc/default/nfs-* are not migrated to /etc/nfs.conf
[14:57] <ahasenack> so if you changed defaults, they won't migrate
[14:57] <ahasenack> I'm currently looking into how to best handle that. There is a migration script from fedora, that I patched a bit and works well
[14:58] <ahasenack> I have to decide on an approach here: do it automatically (postinst?), detect and tell the user to do it manually, with or without the script?
[14:58] <ahasenack> I'm also checking with the debian maintainer, see what his thoughts are
[14:59] <patdk-lap> no good option there :(
[14:59] <patdk-lap> script would seem the best, but I tend to doubt it would work 100% of the time to get the same result, causing unexpected suprise
[14:59] <ahasenack> yeah
[14:59] <patdk-lap> telling the user to do it, is annoying, but it's not unexpected then
[15:00] <ahasenack> middle ground is provide the script, warn that changes were not migrated, and offer the script to help
[15:00] <ahasenack> but I fear that upgrades can really be broken
[15:00] <ahasenack> imagine sites who have used the command line options to specify custom keytabs, or fixed ports
[15:01] <patdk-lap> I personally want to say, those you shouldn't have to worry about
[15:01] <ahasenack> and on a release upgrade, nobody sees those messages
[15:01] <patdk-lap> as someone should be babysitting those upgrades anyways
[15:01] <ahasenack> well, release notes will have some paragraphs about this for sure :)
[15:02] <patdk-lap> I imagine the goal though is to resolve the *home user* that doesn't do that, and just hits upgrade
[15:02] <patdk-lap> being ticket happy
[15:03] <patdk-lap> is there a way to run the script, and then trigger the normal like, this file has changed edit prompt?
[15:05] <ahasenack> what do you mean?
[15:06] <patdk-lap> well, when the upgrader detects a file change, it prompts you, keep current, new, diff, ...
[15:06] <patdk-lap> wonder if you could trigger that after the script run
[15:06] <patdk-lap> that is how I normally add to my review list of things to check over after an upgrade
[15:06] <patdk-lap> before I go into testing all the services
[15:07] <ahasenack> have to think about that
[15:07] <ahasenack> it's a new config file
[15:07] <patdk-lap> ya that is why I don't know if it's possible
[15:07] <ahasenack> there is also the problem of the package changing its own config, and thus  it will prompt on any upgrade thereafter
[15:07] <patdk-lap> if the script could run before that is checked would work, dunno if possible
[15:08] <patdk-lap> well, that would fix that then
[15:08] <patdk-lap> if it prompted on this run, it wouldn't on the next
[15:08] <ahasenack> ok, gotta run, was just called for lunch
[15:08] <patdk-lap> but ya, I doubt it is possible
[15:08] <ahasenack> we'll think about it
[15:08] <ahasenack> we definitely want the new upstream version
[15:20] <jamespage> icey: python3-saml uploaded as well
[16:05] <cpaelzer> ahasenack: no preference about the order
[16:05] <cpaelzer> ahasenack: more depending on your time, ipxe is msall, qemu/libvirt not so much
[16:06] <ahasenack> neither look small :)
[16:09] <cpaelzer> x86 (and only x86) tests also seem to insist on an odd networking issue
[16:09] <cpaelzer> has to be Monday to complete I guess
[16:09] <cpaelzer> and I'm actually no more here :-)
[18:42] <bryceh> php-defaults finally 100% unblocked for migration \o/  https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php-defaults
[19:52] <kanashiro> good work bryceh 
[20:25] <ahasenack> bryceh: woohoo! \o/