GNU bug report logs - #72686
Impossible to remove all offload machines

Previous Next

Full log

Message #14 received at 72686 <at> debbugs.gnu.org (full text, mbox):

From: Ian Eure <ian <at> retrospec.tv>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: guix-devel <guix-devel <at> gnu.org>, 72686 <at> debbugs.gnu.org
Subject: Re: bug#72686: Impossible to remove all offload machines
Date: Sat, 14 Sep 2024 20:53:22 -0700

Hi Maxim,

Ian Eure <ian <at> retrospec.tv> writes:

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
>
>> Hi Ian,
>>
>> Ian Eure <ian <at> retrospec.tv> writes:
>>
>>> Ran into this issue last week.  If you:
>>>
>>> - Configure some offload build machines in your 
>>> operating-system
>>>  configuration.
>>> - Reconfigure your system.
>>> - Remove all offload build machines.
>>> - Reconfigure your system again.
>>>
>>> ...then various guix operations will still try to connect to
>>> offload
>>> machines, even if you reboot the affected client.
>>>
>>> This is caused by a bug in the `guix-activation' procedure:
>>>
>>>   ;; ... and /etc/guix/machines.scm.
>>>   #$(if (null? (guix-configuration-build-machines config))
>>>         #~#f
>>>         (guix-machines-files-installation
>>>          #~(list #$@(guix-configuration-build-machines
>>>           config))))
>>>
>>> If there are no build machines defined in the configuration, 
>>> no
>>> operation is performed (#f is returned), which leaves the 
>>> previous
>>> generation’s /etc/guix/machines.scm in place.
>>>
>>> The same issue appears to affect channels:
>>>
>>>   ;; ... and /etc/guix/channels.scm...
>>>   #$(and channels (install-channels-file channels))
>>
>> Interesting!
>>
>>> I’d be happy to take a stab at fixing this, but I’m not 
>>> certain
>>> what
>>> direction to go, or how much to refactor to get there. Should 
>>> the
>>> channels/machines files be removed (ignoring errors if they 
>>> don’t
>>> exist)?  Should empty files be installed?  Should that happen
>>> inline
>>> in `guix-activation', or in another procedure? Should the 
>>> filenames
>>> be
>>> extracted to %variables to avoid duplicating between the two 
>>> places
>>> they’ll be used?
>>>
>>> If someone would like to provide answered, I would contribute 
>>> a
>>> patch.
>>
>> I guess the simplest would be to attempt to remove the files 
>> when
>> there
>> are no offload machines or channels, in this already existing
>> activation
>> procedure.  Extracting the file names to %variables sounds
>> preferable
>> yes, if there's a logical place to store them that is easily 
>> shared.
>>
>
> As I was putting together a patch for this, I realized there’s a
> problem: if a user is *manually* managing either
> /etc/guix/machines.scm or channels.scm, these files would be 
> deleted,
> which likely isn’t what they want.  The current code lets users 
> choose
> to manage these files manually or declaritively, and there’s no 
> way to
> know if the files on disk are the result of a previous system
> generation or a user’s creation.  Since the channel management 
> is a
> relatively new feature, I suspect there are quite a few folks 
> with
> manually-managed channels that this would negatively impact.  I 
> know
> there was some disruption just moving to declaritive management 
> of
> channels (but I can’t find the thread/s at the moment).
>
> I don’t see an elegant technical solution to this.  I think the 
> best
> option is probably to say that those files should *always* be 
> managed
> through operating-system, and put a fat warning in the channel 
> news to
> update your config if they’re still handled manually.
>
> The only other option I can see would be to keep the existing
> filenames for user configuration, and declaritively manage 
> different
> files -- like declaritive-channels.scm.  This comes with its own 
> set
> of problems, like needing to update the Guix daemon to read and
> combine multiple files; and the inability to know whether a 
> given
> `channels.scm' is declaritively- or manually-managed means a 
> bumpy
> upgrade path (ex. should this preexisting channels.scm file be 
> left
> as-is, or renamed to the new name?)
>
> I’m inclined to go with the fat-warning option, but am also 
> thinking
> this likely needs some guix-devel discussion.
>
> What do you think?
>

Disregard this, I continued thinking after sending the email (as 
one does) and realized that any managed file will be a link into 
the store -- so if the system is reconfigured with no 
build-machines or channels *and* the corresponding file is a store 
link, it should be removed; otherwise, it should remain untouched. 
I can work with this.

Thanks,

 — Ian

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.