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