Hi Chris and Dave,

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

> Hi,
>
> On Wed, Aug 7, 2019 at 2:31 PM Christopher Lemmer Webber
> <cwebber@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