From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:46368) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hvREB-0006sc-RD for guix-patches@gnu.org; Wed, 07 Aug 2019 15:04:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hvREA-0005gI-PR for guix-patches@gnu.org; Wed, 07 Aug 2019 15:04:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:58794) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hvREA-0005eV-DK for guix-patches@gnu.org; Wed, 07 Aug 2019 15:04:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hvREA-0000XS-88 for guix-patches@gnu.org; Wed, 07 Aug 2019 15:04:02 -0400 Subject: [bug#36872] [PATCH 2/2] remote: Remove '--system' argument. Resent-Message-ID: MIME-Version: 1.0 References: <87lfwee2yd.fsf@sdf.lonestar.org> <87h872e2v2.fsf@sdf.lonestar.org> <87ef1yovur.fsf@dustycloud.org> <877e7qvv75.fsf@sdf.lonestar.org> <87a7ckq129.fsf@dustycloud.org> In-Reply-To: <87a7ckq129.fsf@dustycloud.org> From: "Thompson, David" Date: Wed, 7 Aug 2019 15:03:06 -0400 Message-ID: Content-Type: text/plain; charset="UTF-8" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Christopher Lemmer Webber Cc: 36872@debbugs.gnu.org Hi, On Wed, Aug 7, 2019 at 2:31 PM Christopher Lemmer Webber 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