[bug#36872] [PATCH 2/2] remote: Remove '--system' argument.

["Thompson, David" <dthompson2@worcester.edu>]

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?

- Dave