Hi,
On Tue, Jan 16, 2024 at 3:02 AM Steve Langasek <steve.langasek@ubuntu.com> wrote:
On Fri, Jan 12, 2024 at 11:05:24AM -0500, Nick Rosbrook wrote:
> Hi,
> > I guess something in do-release-upgrade could be run to, when encountering such a situation, automatically select bin:samba-vfs-modules-extra for the upgrade as well? Is it worth it? Is there a precedence for something like this? And how would this be done in a more generic/general case, if at all?
> We have the concept of "quirks"[1] in ubuntu-release-upgrader which
> allows us to handle special cases like this. For example, a cycle or
> two ago when flatpak was removed from flavor seeds, we added some code
> to not auto-remove flatpak if it appeared the user was actively using
> it. So yes, if nothing else we could add a quirk to make sure
> samba-vfs-modules-extra is installed upgrades if samba-vfs-modules is
> currently installed.
I want to weigh in here to say that I think we should NOT do this by
default.
In my view, every difference between "Install Ubuntu release X; upgrade to
Ubuntu release X+1" and "Install Ubuntu release X+1" is a bug.
These bugs vary in severity, and we'll probably never zero out the list of
such bugs. But we should not knowingly *introduce* such bugs through
quirking.
Something I could to to gather data is to do an actual deployment using glusterfs (of samba and qemu), upgrade, lose the gluster modules, and see what happens.
If do-release-upgrade fails outright (because some postinst failed due to the missing gluster module), then I guess it's a high prio bug and we should proceed with the do-release-upgrade quirks.
If the upgrade finishes, the system reboots, and then services don't come back up due to the missing glusterfs modules, and that can be fixed by just an "apt install <pkg>", then it's less severe and can be release-noted. But the quirk would also solve this situation, and I thought it wouldn't be such a bad approach.
This should also apply to "Install Ubuntu release X; apt install Y; upgrade
to Ubuntu release X+1", when not modifying any configuration files along the
way (though the severity of such a bug should also understandably be lower).
If it's possible to detect that the system in question is *using* glusterfs,
and add a quirk at runtime to install samba-vfs-modules-extra, then I think
this sort of change is ok. Otherwise, I think the right answer here is:
I admit that I was thinking about just checking if `samba-vfs-modules` is installed in noble-1, and then mark samba-vfs-modules-extra for installation.
I can do *some* detection of glusterfs usage via testparm[1] on the main config file, but it will miss some cases:
- included dynamic files, like "include = /etc/samba/%U.conf" (which file that will be is not known before an actual connection to the share)
- registry-based configurations (due to my lack of experience in that, I suppose `sudo net conf list` would list it all)
And registry-based[2] happens to be the preferred way to configure a clustered samba server (with glusterfs as the backend).
This is of course way more complex than the first approach.
