From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?G=C3=A1bor_Boskovits?= Subject: Re: Installation Date: Mon, 22 Jan 2018 09:29:42 +0100 Message-ID: References: <87mv1c4kp7.fsf@gnu.org> <87k1wgh4hf.fsf@elephly.net> <877esfbgtx.fsf@gnu.org> <87372yzewz.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a1140ba965c6b160563593b80" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:47774) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1edXUD-0006y3-6M for guix-devel@gnu.org; Mon, 22 Jan 2018 03:29:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1edXUB-00017p-FM for guix-devel@gnu.org; Mon, 22 Jan 2018 03:29:49 -0500 In-Reply-To: <87372yzewz.fsf@gmail.com> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Chris Marusich Cc: Guix-devel --001a1140ba965c6b160563593b80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2018-01-22 5:38 GMT+01:00 Chris Marusich : > ludo@gnu.org (Ludovic Court=C3=A8s) writes: > > > Ricardo Wurmus skribis: > > > >> Ludovic Court=C3=A8s writes: > >> > >>> G=C3=A1bor Boskovits 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? :-) > >>> > >>> =E2=80=98operating-system=E2=80=99 *is* an =E2=80=9Cinstallation desc= ription.=E2=80=9D > >> > >> I guess it would differ from what we have currently in that it would > >> also specify partitioning information, which is not handled by > >> =E2=80=9Coperating-system=E2=80=9D. > >> > >> Does it make sense to extend =E2=80=9Coperating-system=E2=80=9D such t= hat disk > >> partitioning information could be included and (*holds breath*) acted > >> upon automatically? > > > > I suppose only =E2=80=98guix system init=E2=80=99 could actually use th= at information. > > > > Perhaps we could have a separate partitioning description, and users > > could optionally run: > > > > guix system init --partitioning=3Dpart.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 le= ad > >> to data loss upon reconfiguration. Small bugs could lead to very big > >> problems, so maybe this should not be default behaviour. > > > > It=E2=80=99s definitely scary. > > > > Ludo=E2=80=99. > > 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 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 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 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 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 > --001a1140ba965c6b160563593b80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
2018= -01-22 5:38 GMT+01:00 Chris Marusich <cmmarusich@gmail.com>:
ludo@gnu.org (Ludovic Court=C3=A8s) = writes:

> Ricardo Wurmus <rekado@elephl= y.net> skribis:
>
>> Ludovic Court=C3=A8s <ludo@gnu.= org> writes:
>>
>>> G=C3=A1bor Boskovits <boskovits@gmail.com> skribis:
>>>
>>>> I believe, that we could make a powerful extension to guix= sd 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?=C2=A0 :-)
>>>
>>> =E2=80=98operating-system=E2=80=99 *is* an =E2=80=9Cinstallati= on description.=E2=80=9D
>>
>> I guess it would differ from what we have currently in that it wou= ld
>> also specify partitioning information, which is not handled by
>> =E2=80=9Coperating-system=E2=80=9D.
>>
>> Does it make sense to extend =E2=80=9Coperating-system=E2=80=9D su= ch that disk
>> partitioning information could be included and (*holds breath*) ac= ted
>> upon automatically?
>
> I suppose only =E2=80=98guix system init=E2=80=99 could actually use t= hat information.
>
> Perhaps we could have a separate partitioning description, and users > could optionally run:
>
>=C2=A0 =C2=A0guix system init --partitioning=3Dpart.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 easil= y lead
>> to data loss upon reconfiguration.=C2=A0 Small bugs could lead to = very big
>> problems, so maybe this should not be default behaviour.
>
> It=E2=80=99s definitely scary.
>
> Ludo=E2=80=99.

Currently, I can only imagine two possible ways this might be u= sed:

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?=C2=A0 I know of no developers or<= br> users who actually need to change these things frequently.=C2=A0 And when changes to these things ARE necessary, it's usually easier to just blas= t
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.=C2=A0 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.=C2=A0 Maybe a company wants to<= br> provision many GuixSD systems for employee laptops.=C2=A0 Maybe somebody needs to provision many GuixSD servers in a datacenter.=C2=A0 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?=C2=A0 Maybe.=C2=A0 For ex= ample,
maybe we can fields to the <operating-system> declaration which are o= nly
acted upon by "guix system init".=C2=A0 The intended workflow wou= ld be: boot
a GuixSD installation image, then run "guix system init" per the = manual
(perhaps via a script, or even a "guix-provisioning-service" star= ted 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.=C2=A0 THIS could be nic= e!

Of course, someone who is provisioning systems like this already has the option of creating custom scripts and tools to initialize the system's<= br> drives, partitions, and file systems, but wouldn't it be nice if Guix could do this on their behalf, also?=C2=A0 If these details were all define= d
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 contain= s
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 in= frastructure
provisioning. Usually there is no expilcit need to d= o this after initialization.
If manipulation of partitions should= be done later, then it can be solved
by the tools we already hav= e. One exception that comes to my mind is
lvm and zfs/btrfs subvo= lume creation for vms, but that is on the vm provisioning layer.
=
I would really like to see guixsd on the infrastructure laye= r, because the current
situation is quite problematic.=C2=A0
--
Chris

--001a1140ba965c6b160563593b80--