From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?G=C3=A1bor_Boskovits?= Subject: Re: Installation Date: Wed, 17 Jan 2018 20:35:14 +0100 Message-ID: References: <87mv1c4kp7.fsf@gnu.org> <87k1wgh4hf.fsf@elephly.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="94eb2c11cb484d72ad0562fdf235" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53643) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ebtUU-00052c-UJ for guix-devel@gnu.org; Wed, 17 Jan 2018 14:35:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ebtUT-0006uT-OF for guix-devel@gnu.org; Wed, 17 Jan 2018 14:35:18 -0500 In-Reply-To: <87k1wgh4hf.fsf@elephly.net> 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: Ricardo Wurmus Cc: Guix-devel --94eb2c11cb484d72ad0562fdf235 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2018-01-17 16:47 GMT+01:00 Ricardo Wurmus : > > 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 descri= ption.=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 that= disk > partitioning information could be included and (*holds breath*) acted > upon automatically? > > 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. > > Yes, partitioning information is one of the primary missing point for me. I don't think that it should be default behaviour either. Another thing tha= t could be useful is secret provisioning in some form. I am thinking of this as a base of a bare-metal provisioning framework. We could get some ideas, what else the other tools are doing. I guess I've also read something about guix deploy. What is the current status of that? One more thing: lvm really seems not to map well onto the current set of storage primitives. I guess that lvm support could be added more cleanly with this kind of mapping: Partition -> PV Mapped device of PVs -> volume group Partition of volume group -> LV -- > Ricardo > > GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC > https://elephly.net > > > --94eb2c11cb484d72ad0562fdf235 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
2018= -01-17 16:47 GMT+01:00 Ricardo Wurmus <rekado@elephly.net>:=

Ludovic Court=C3=A8s <ludo@gnu.org&g= t; writes:

> G=C3=A1bor Boskovits <boskov= its@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 operati= ng-system description we
>> already have.
>
> In what way would it defer?=C2=A0 :-)
>
> =E2=80=98operating-system=E2=80=99 *is* an =E2=80=9Cinstallation descr= iption.=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 that d= isk
partitioning information could be included and (*holds breath*) acted
upon automatically?

Acting on partitioning info is a little scary because it can easily lead to data loss upon reconfiguration.=C2=A0 Small bugs could lead to very big<= br> problems, so maybe this should not be default behaviour.


Yes, partitioning information is one o= f the primary missing point for me.
I don't think that it sho= uld be default behaviour either. Another thing that
could be usef= ul is secret provisioning in some form.

I am think= ing of this as a base of a bare-metal provisioning framework.
We = could get some ideas, what else the other tools are doing.
=C2=A0=
I guess I've also read something about guix deploy. What is = the current status of that?

One more thing: lvm re= ally seems not to map well onto the current set of storage primitives.
I guess that lvm support could be added more cleanly with this kind o= f mapping:

Partition -> PV
Mapped dev= ice of PVs -> volume group
Partition of volume group -> LV<= /div>

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6=C2=A0 2150 197A 5888 235F ACAC
https:= //elephly.net



--94eb2c11cb484d72ad0562fdf235--