Re: Implementing guix system rollback / switch-generation

[Chris Marusich]

address@hidden (Ludovic Courtès) writes:

> The problem with system rollback, as you’ve seen, is that we lack
> information about the old system, such as what its activation script is
> and what its Shepherd services are.
>
> We could add the activation script’s file name to the ‘parameters’ file
> that you see in the result of ‘guix system build foo.scm’.  But it would
> be hard to add a forward-compatible yet complete description of the
> Shepherd services there.

That makes sense.  I can't think of a better way to get the information
without access to the original operating system configuration file.

> ISTR that GRUB has a mechanism to record the last selected menu entry
> and to use that as the next default entry.
>
> Now, it’s not always what one would want to do.
>
> However, ‘guix system roll-back/switch-generation’ could generate a
> grub.cfg where the default menu entry points to whatever old generation
> has been selected.

Thank you for letting me know about that GRUB feature.  I didn't know
about it; I'll look into it more.  In any case, I do expect that a
roll-back/switch-generation command would modify the default GRUB menu
entry, since "guix system reconfigure" does the same.

> It’s not possible to obtain past grub.cfg files, but that’s not a
> problem: we can always regenerate a new grub.cfg.

I'm curious: is there a reason why /boot is not itself just another
symlink?  It might be nice if instead of overwriting the grub.cfg file,
we could just flip a symlink when rolling back.

> What seems more difficult to me is Shepherd services.  Maybe we could
> store in the system output (result of ‘guix system build’) an sexp
> representation of (part of) our <shepherd-service> records:
>
>   (shepherd-service
>     (provisions (x y z))
>     (requirements (a b c))
>     (start-script "/gnu/store/…-start-foo.scm")
>     (stop-script "/gnu/store/…-stop-foo.scm")
>     …)
>
> Then ‘upgrade-shepherd-services’ could start from this simplified
> representation instead of using the full-blown <shepherd-service>
> objects, and thus could work both when instantiating a new generation
> and when rolling back.

Yes, without access to the original operating system configuration file,
something like this seems like the best (or only?) way.

>> More generally, are people satisfied with the way system rollback is
>> currently implemented in GuixSD?
>
> Personally I’m not fully satisfied, but it’s true that it covers my main
> use case, which is to recover from a broken update.
>
> I had never thought about live “downgrade” of services when rolling
> back, because the only times where I’ve wanted to roll back is right
> after booting (or trying to boot ;-)) into a new system generation.

I think the current rollback mechanism is very usable if you just need
to roll back a small number of machines, and you have a way to manually
select the GRUB menu entries.  However, I'm not sure it would be easy to
roll back many machines remotely, so it would be nice if it were easier.

>> Do you think that the mechanism I'm proposing is a bad idea?  I'd hate
>> to try to implement something that nobody else thinks is needed.
>
> I think having basic delete-generations, switch-generations, and
> roll-back sub-commands would be definitely welcome.
>
> As a first step, switch-generations/roll-back commands could simply
> update the symlinks and regenerate grub.cfg.
>
> Milestone #2 would be running the previous system’s activation script,
> which installs /run/current-system and adjust the set of users and
> groups.
>
> Milestone #3 would be live service downgrade, as you describe.
>
> Thoughts?

I think breaking it down like that makes a lot of sense.  I'll give
milestone #1 a shot: make switch-generations/roll-back commands that
just update the symlinks and regenerate grub.cfg.

Thank you for the input!

-- 
Chris

signature.asc
Description: PGP signature