Re: Installation

["Gábor Boskovits" <boskovits@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5238 bytes --]

2018-01-22 5:38 GMT+01:00 Chris Marusich <cmmarusich@gmail.com>:

> ludo@gnu.org (Ludovic Courtès) writes:
>
> > Ricardo Wurmus <rekado@elephly.net> skribis:
> >
> >> Ludovic Courtès <ludo@gnu.org> writes:
> >>
> >>> Gábor Boskovits <boskovits@gmail.com> 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
>

[-- Attachment #2: Type: text/html, Size: 6590 bytes --]