Re: Installation

[Gábor Boskovits]

2018-01-22 5:38 GMT+01:00 Chris Marusich <address@hidden>:

address@hidden (Ludovic Courtès) writes:

> Ricardo Wurmus <address@hidden> skribis:
>
>> Ludovic Courtès <address@hidden> writes:
>>
>>> Gábor Boskovits <address@hidden> skribis:
>>>
>>>> I believe, that we could make a powerful extension to guixsd if we could do
>>>> an installation from an installation description.
>>>>
>>>> I think this installation description should look like the operating-system description we
>>>> already have.
>>>
>>> In what way would it defer?  :-)
>>>
>>> ‘operating-system’ *is* an “installation description.”
>>
>> I guess it would differ from what we have currently in that it would
>> also specify partitioning information, which is not handled by
>> “operating-system”.
>>
>> Does it make sense to extend “operating-system” such that disk
>> partitioning information could be included and (*holds breath*) acted
>> upon automatically?
>
> I suppose only ‘guix system init’ could actually use that information.
>
> Perhaps we could have a separate partitioning description, and users
> could optionally run:
>
>   guix system init --partitioning=part.scm config.scm
>
> ?
>
> Is it really an improvement over writing a Parted script, which is
> something people can already do?
>
>> Acting on partitioning info is a little scary because it can easily lead
>> to data loss upon reconfiguration.  Small bugs could lead to very big
>> problems, so maybe this should not be default behaviour.
>
> It’s definitely scary.
>
> Ludo’.

Currently, I can only imagine two possible ways this might be used:

1) Somebody wants to frequently change the hard drives, partitions,
and/or file systems in their computer(s).

2) Somebody wants to initialize the hard drives, partitions, and/or file
systems in their computer(s), but doesn't need to update it later.

In the case of (1), who really does this?  I know of no developers or
users who actually need to change these things frequently.  And when
changes to these things ARE necessary, it's usually easier to just blast
everything away and start fresh (restoring what you need from a backup
later), rather than trying to figure out the right way to safely modify
things in place.  Since changing these kinds of things on a system
that's already in use is a rare and dangerous activity, I'm not
convinced that Guix needs to provide support for this use case.

In the case of (2), anybody who frequently needs to provision systems
will probably have a use case for this, so it might make sense to add a
feature for first-time initialization only.  Maybe a company wants to
provision many GuixSD systems for employee laptops.  Maybe somebody
needs to provision many GuixSD servers in a datacenter.  I think that if
somebody really needs to do this sort of provisioning frequently,
they're probably going to implement their own custom workflow to
accomplish the task.

Can Guix add a feature to make their life easier?  Maybe.  For example,
maybe we can fields to the <operating-system> declaration which are only
acted upon by "guix system init".  The intended workflow would be: boot
a GuixSD installation image, then run "guix system init" per the manual
(perhaps via a script, or even a "guix-provisioning-service" started by
Shepherd...!), and Guix will do everything it does today to initialize
the system, but first it will also destructively initialize the hard
drives, partitions, and file systems according to what is contained in
the specified <operating-system> declaration.  THIS could be nice!

Of course, someone who is provisioning systems like this already has the
option of creating custom scripts and tools to initialize the system's
drives, partitions, and file systems, but wouldn't it be nice if Guix
could do this on their behalf, also?  If these details were all defined
in the <operating-system> declaration, then (1) the user wouldn't have
to implement those kinds of tools themselves, and (2) it would reduce the
possibility of writing an <operating-system> declaration that contains
incorrect information about disks, partitions, or file systems because
all that information would be contained in a single file.

I think the key here is that if Guix provides a way to manipulate disks,
partitions, or file systems, it should only be allowed when initializing
a new system - not reconfiguring an existing one.

I agree with this. And the use case I have in mind is datacenter infrastructure

provisioning. Usually there is no expilcit need to do this after initialization.

If manipulation of partitions should be done later, then it can be solved

by the tools we already have. One exception that comes to my mind is

lvm and zfs/btrfs subvolume creation for vms, but that is on the vm provisioning layer.

I would really like to see guixsd on the infrastructure layer, because the current

situation is quite problematic. 

--
Chris