[bug#36738] guix deploy: Support '--no-grafts' and '--system'

Hello, this patch handle the '--no-grafts' command line option:
And '--system', so I can deploy a "i686-linux" from my "x86_64-linux":
Or better we can add a 'system' field to the <machine> record, so we can
deploy a list of machines with different 'system'.  Currently a
<machine> has 'system' as a field for the <operating-system>, so where
to put this machine/arch 'system'...

Hello Wenwu,
iyzsong@member.fsf.org (宋文武) writes:

> Hello, this patch handle the '--no-grafts' command line option:
> ...
> And '--system', so I can deploy a "i686-linux" from my "x86_64-linux":

These patches look good to me, thank you!

Ludo, Dave, Chris, any additional comments?

> Or better we can add a 'system' field to the <machine> record, so we
> can deploy a list of machines with different 'system'. Currently a
> <machine> has 'system' as a field for the <operating-system>, so where
> to put this machine/arch 'system'...

Great idea. I think that continuing to call the machine's
<operating-system> 'system' would be confusing if we introduced the
notion of a target architecture, because we use "system" to refer to the
target architecture in the rest of Guix's command-line tools. Maybe it
would make sense to rename the <operating-system> field to 'os' or
something similar, and use the 'system' field to specify the target
architecture instead? Any thoughs?

Regards,
Jakob

zerodaysfordays@sdf.lonestar.org (Jakob L. Kreuze) writes:

> Great idea. I think that continuing to call the machine's
> <operating-system> 'system' would be confusing if we introduced the
> notion of a target architecture, because we use "system" to refer to
> the target architecture in the rest of Guix's command-line tools.
> Maybe it would make sense to rename the <operating-system> field to
> 'os' or something similar, and use the 'system' field to specify the
> target architecture instead? Any thoughs?

Actually, I had a thought. Why should we make this explicit, when we
could take an implicit approach and identify the target's architecture
with 'remote-eval'? Ideally, we'll be probing the machines anyway to
implement safety checks on the <operating-system> declaration, so why
not just add this to our list of pre-deployment tests?

Regards,
Jakob

Jakob L. Kreuze writes:

> Hello Wenwu,
> iyzsong@member.fsf.org (宋文武) writes:
>
>> Hello, this patch handle the '--no-grafts' command line option:
>> ...
>> And '--system', so I can deploy a "i686-linux" from my "x86_64-linux":
>
> These patches look good to me, thank you!
>
> Ludo, Dave, Chris, any additional comments?
>
>> Or better we can add a 'system' field to the <machine> record, so we
>> can deploy a list of machines with different 'system'. Currently a
>> <machine> has 'system' as a field for the <operating-system>, so where
>> to put this machine/arch 'system'...
>
> Great idea. I think that continuing to call the machine's
> <operating-system> 'system' would be confusing if we introduced the
> notion of a target architecture, because we use "system" to refer to the
> target architecture in the rest of Guix's command-line tools. Maybe it
> would make sense to rename the <operating-system> field to 'os' or
> something similar, and use the 'system' field to specify the target
> architecture instead? Any thoughs?

I'm fine with a rename to "os"

Jakob L. Kreuze writes:

> zerodaysfordays@sdf.lonestar.org (Jakob L. Kreuze) writes:
>
>> Great idea. I think that continuing to call the machine's
>> <operating-system> 'system' would be confusing if we introduced the
>> notion of a target architecture, because we use "system" to refer to
>> the target architecture in the rest of Guix's command-line tools.
>> Maybe it would make sense to rename the <operating-system> field to
>> 'os' or something similar, and use the 'system' field to specify the
>> target architecture instead? Any thoughs?
>
> Actually, I had a thought. Why should we make this explicit, when we
> could take an implicit approach and identify the target's architecture
> with 'remote-eval'? Ideally, we'll be probing the machines anyway to
> implement safety checks on the <operating-system> declaration, so why
> not just add this to our list of pre-deployment tests?
>
> Regards,
> Jakob

Maybe a good idea... let me think.  Is there any case where we start
taking actions *before* we might probe a machine that we can think of?

How would we also probe it?  Is there a chance of our probing behaving
incorrectly?  That would also be bad, if so.

Another route is to have the user specify what architecture they think
the machine has, and instead the probing is a "safety check"?

On Mon, Jul 22, 2019 at 6:48 PM Jakob L. Kreuze
<zerodaysfordays@sdf.lonestar.org> wrote:
>
> zerodaysfordays@sdf.lonestar.org (Jakob L. Kreuze) writes:
>
> > Great idea. I think that continuing to call the machine's
> > <operating-system> 'system' would be confusing if we introduced the
> > notion of a target architecture, because we use "system" to refer to
> > the target architecture in the rest of Guix's command-line tools.
> > Maybe it would make sense to rename the <operating-system> field to
> > 'os' or something similar, and use the 'system' field to specify the
> > target architecture instead? Any thoughs?
>
> Actually, I had a thought. Why should we make this explicit, when we
> could take an implicit approach and identify the target's architecture
> with 'remote-eval'? Ideally, we'll be probing the machines anyway to
> implement safety checks on the <operating-system> declaration, so why
> not just add this to our list of pre-deployment tests?

I don't see a compelling reason for the architecture to be a part of
the machine data type at this time.  I'd like to avoid such low-level
details if possible because I don't think they will translate well to
more complex methods of deployment.

- Dave

Hi Chris,

Christopher Lemmer Webber <cwebber@dustycloud.org> writes:

> Maybe a good idea... let me think. Is there any case where we start
> taking actions *before* we might probe a machine that we can think of?
>
> How would we also probe it? Is there a chance of our probing behaving
> incorrectly? That would also be bad, if so.

None that come to mind right now, and if there are any, I don't think
they would be affected by the probing -- aside from doing work that
would get thrown out when the script errors out.

As for the safety of probing, none of the tests I intend on implementing
are effectful. It would be equivalents for 'check-mapped-devices',
'check-file-system-availability', and 'check-initrd-modules', all of
which do little beyond looking at the devices available on the system,
and now a check that would read '%current-system'.

> Another route is to have the user specify what architecture they think
> the machine has, and instead the probing is a "safety check"?

That'd work too, but I feel it's better to avoid putting an unnecessary
burden on the user.

Regards,
Jakob

"Thompson, David" <dthompson2@worcester.edu> writes:

> I don't see a compelling reason for the architecture to be a part of
> the machine data type at this time. I'd like to avoid such low-level
> details if possible because I don't think they will translate well to
> more complex methods of deployment.

A good point. I'll see about having this as an environment-specific
check.

Regards,
Jakob

Hello,

zerodaysfordays@sdf.lonestar.org (Jakob L. Kreuze) skribis:

> Hello Wenwu,
> iyzsong@member.fsf.org (宋文武) writes:
>
>> Hello, this patch handle the '--no-grafts' command line option:
>> ...
>> And '--system', so I can deploy a "i686-linux" from my "x86_64-linux":
>
> These patches look good to me, thank you!
>
> Ludo, Dave, Chris, any additional comments?

Fine with me!

I agree with Dave that we should avoid adding a ‘system-type’ field to
<machine>, at least for now.  Instead, we should just honor
(%current-system).

Thanks,
Ludo’.

Christopher Lemmer Webber <cwebber@dustycloud.org> writes:

> Jakob L. Kreuze writes:
>
>> zerodaysfordays@sdf.lonestar.org (Jakob L. Kreuze) writes:
>>
>>> Great idea. I think that continuing to call the machine's
>>> <operating-system> 'system' would be confusing if we introduced the
>>> notion of a target architecture, because we use "system" to refer to
>>> the target architecture in the rest of Guix's command-line tools.
>>> Maybe it would make sense to rename the <operating-system> field to
>>> 'os' or something similar, and use the 'system' field to specify the
>>> target architecture instead? Any thoughs?
>>
>> Actually, I had a thought. Why should we make this explicit, when we
>> could take an implicit approach and identify the target's architecture
>> with 'remote-eval'? Ideally, we'll be probing the machines anyway to
>> implement safety checks on the <operating-system> declaration, so why
>> not just add this to our list of pre-deployment tests?
>>
>> Regards,
>> Jakob
>
> Maybe a good idea... let me think.  Is there any case where we start
> taking actions *before* we might probe a machine that we can think of?

I don’t know if this qualifies, but if “guix deploy” were to *create* a
machine (e.g. on EC2 via the Guile AWS library) it wouldn’t be able to
probe it first.  But in that case we would have full control over what
the target would be, so no probing would be required.

--
Ricardo

Hi Ricardo,

Ricardo Wurmus <rekado@elephly.net> writes:

> I don’t know if this qualifies, but if “guix deploy” were to *create*
> a machine (e.g. on EC2 via the Guile AWS library) it wouldn’t be able
> to probe it first. But in that case we would have full control over
> what the target would be, so no probing would be required.

Ah, good point. I suppose didn't think about this all the way through in
my response -- we wouldn't be able to probe an unprovisioned machine.
But your point gives me even more confidence in the decision to deduce
target architecture at runtime and have that as an environment-specific
check.

Thanks for chiming in!

Regards,
Jakob

Ludovic Courtès <ludo@gnu.org> writes:

> Hello,
>
> zerodaysfordays@sdf.lonestar.org (Jakob L. Kreuze) skribis:
>
>> Hello Wenwu,
>> iyzsong@member.fsf.org (宋文武) writes:
>>
>>> Hello, this patch handle the '--no-grafts' command line option:
>>> ...
>>> And '--system', so I can deploy a "i686-linux" from my "x86_64-linux":
>>
>> These patches look good to me, thank you!
>>
>> Ludo, Dave, Chris, any additional comments?
>
> Fine with me!
>
> I agree with Dave that we should avoid adding a ‘system-type’ field to
> <machine>, at least for now.  Instead, we should just honor
> (%current-system).
>
> Thanks,
> Ludo’.

Pushed, thanks for the reviews!