[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#36872] [PATCH 2/2] remote: Remove '--system' argument.
From: |
Jakob L. Kreuze |
Subject: |
[bug#36872] [PATCH 2/2] remote: Remove '--system' argument. |
Date: |
Wed, 07 Aug 2019 16:28:19 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) |
Hi Chris and Dave,
"Thompson, David" <address@hidden> writes:
> Hi,
>
> On Wed, Aug 7, 2019 at 2:31 PM Christopher Lemmer Webber
> <address@hidden> 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
Description: PGP signature
- [bug#36872] [PATCH 2/2] remote: Remove '--system' argument., Christopher Lemmer Webber, 2019/08/06
- [bug#36872] [PATCH v2 1/2] remote: Build derivations appropriate for the remote's, Jakob L. Kreuze, 2019/08/06
- [bug#36872] [PATCH 2/2] remote: Remove '--system' argument., Jakob L. Kreuze, 2019/08/06
- [bug#36872] [PATCH 2/2] remote: Remove '--system' argument., Christopher Lemmer Webber, 2019/08/07
- [bug#36872] [PATCH 2/2] remote: Remove '--system' argument., Thompson, David, 2019/08/07
- [bug#36872] [PATCH 2/2] remote: Remove '--system' argument.,
Jakob L. Kreuze <=
- [bug#36872] [PATCH v2 1/2] remote: Build derivations appropriate for the remote's, Jakob L. Kreuze, 2019/08/09
- [bug#36872] [PATCH v2 2/2] remote: Remove '--system' argument., Jakob L. Kreuze, 2019/08/09
- [bug#36872] [PATCH v2 2/2] remote: Remove '--system' argument., Christopher Lemmer Webber, 2019/08/14
- bug#36872: [PATCH v2 2/2] remote: Remove '--system' argument., Christopher Lemmer Webber, 2019/08/14