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

Previous Next

Full log

View this message in rfc822 format

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: bug#72686: Impossible to remove all offload machines
Date: Sat, 14 Sep 2024 20:24:38 -0700

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?

Thanks,

 — Ian

Previous Next

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