GNU bug report logs - #36872
[PATCH 1/2] remote: Build derivations appropriate for the remote's architecture.

Previous Next

Full log

Message #32 received at 36872 <at> debbugs.gnu.org (full text, mbox):

From: zerodaysfordays <at> sdf.lonestar.org (Jakob L. Kreuze)
To: "Thompson\, David" <dthompson2 <at> worcester.edu>
Cc: Christopher Lemmer Webber <cwebber <at> dustycloud.org>, 36872 <at> debbugs.gnu.org
Subject: Re: [bug#36872] [PATCH 2/2] remote: Remove '--system' argument.
Date: Wed, 07 Aug 2019 16:28:19 -0400

[Message part 1 (text/plain, inline)]

Hi Chris and Dave,

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

> Hi,
>
> On Wed, Aug 7, 2019 at 2:31 PM Christopher Lemmer Webber
> <cwebber <at> dustycloud.org> wrote:
>>
>> I thought about it more between yesterday and today, and it continues to
>> seem strange to me that we're doing "probing" here.  We don't probe to
>> guess where Guix is currently installed or etc to specify disks.  I
>> guess that's not the same thing, but...
>>
>> Here's the concern: imagine that we want to be able to up-front do
>> something like "guix system build" before we even start spinning up
>> servers.  Does this block that direction?
>
> This is a good point.  We want to make sure that the config file
> *completely* describes the operating systems that need to be built,
> therefore having to talk to a remote machine is no bueno.  The reason
> I didn't want the user to have to explicitly specify the remote
> system's architecture is for usability.  I wanted 'guix deploy' to
> just DTRT like guix already does when you run `guix system
> reconfigure` or `guix build` locally where %current-system defaults to
> what the local machine is running.  However, I think that providing
> this information would only be a small inconvenience for the current
> managed host environment type. This wouldn't be an issue at all for an
> AWS environment type, for example, because the user would have to
> specify which instance type they want and with that you know what the
> value of %current-system should be when generating the OS derivation.
> I imagine this would be the case for any cloud environment.
>
> I think I've said this before (not sure if IRL or in an email) that we
> should make it the responsibility of the environment type to determine
> what the remote machine's system is.  I still think that should be the
> case, but we should change the managed host type so that the user
> specifies that information as a new record field rather than making
> 'guix deploy' probe for it.
>
> Does this make sense?

Right. My gut feels a bit conflicted since 'remote-eval' is already
talking to the remote, but the points about building ahead of time and
having the configuration file completely specify the deployment are
strong -- perhaps the better thing to do is to add a 'system' keyword to
'remote-eval'. I'll redo this patch as a 'system' field for the
'managed-host-environment-type' configuration.

Regards,
Jakob

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.