Re: bug#72686: Impossible to remove all offload machines

[Ian Eure <ian@retrospec.tv>]

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Hi Ian,
>
> Ian Eure <ian@retrospec.tv> writes:
>
> [...]
>
>> 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'd think that be a great option to pursue, although it's more 
> work more
> thoughts.  Perhaps it could work along these lines 
> (brainstorming)
>
> I like the idea to leave the original, potentially manually 
> written file
> in place and complement it with a declarative counterpart.  The 
> same
> would also have benefited /etc/guix/acl, which suffers from the 
> same
> ambiguity.
>

Apologies for the silence, life stuff has been eating most of my 
free time, but I have a bit of bandwidth to spend on this problem 
again.

I took a swing at this, it wasn’t as difficult as I expected. 
While this approach gives a smooth upgrade path for those who’ve 
configured channels in a stateful way switching to declarative 
configuration, it’s possibly bumpy for those already using a 
declarative config.  If a machine with declarative channels is 
reconfigured, the channels will be duplicated from 
/etc/guix/channels.scm to /etc/guix/channels-declarative.scm. 
Using `delete-duplicates' on the merged channels should avoid 
major problems, but I think it still needs a loud entry in news 
and manual action (deleting /etc/guix/channels.scm) to upgrade. 
Given that both approaches will require manual action, I’m a bit 
inclined to go with the simpler, and take over the existing file. 
That said, I think the failure mode of the simpler approach 
(stomping on channels a user may have configured) is undeniably 
worse than potentially duplicating channels or continuing to pull 
in old ones unexpectedly.  Do either of you have a strong opinion 
or more information which would help guide this decision?

The root issue at work behind all these problems is that 
activation code only sees the desired target config, rather than 
the current and target configs.  Comparing the current and target 
configs would allow the code to more precisely compute the needd 
change to move from one state to the next.  I think that could be 
a good change to make, though it’s obviously going to be much more 
involved, and IMO will require discussion outside the scope of 
this specific bug.

I have a draft patch series I hope to send up soon, but need to 
get Guix System up in a VM to test first.  It does separate 
declarative channels into their own config, but doesn’t do the 
same for build machines.  While I think many fewer users configure 
build machines than channels, it’s probably a good idea to use the 
same approach for both channels and machines.

  — Ian