From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:33162) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hvSbO-00021Y-W6 for guix-patches@gnu.org; Wed, 07 Aug 2019 16:32:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hvSbN-0007t2-OB for guix-patches@gnu.org; Wed, 07 Aug 2019 16:32:06 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:58936) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hvSbK-0007md-HA for guix-patches@gnu.org; Wed, 07 Aug 2019 16:32:03 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hvSbK-00076Q-D1 for guix-patches@gnu.org; Wed, 07 Aug 2019 16:32:02 -0400 Subject: [bug#36872] [PATCH 2/2] remote: Remove '--system' argument. Resent-Message-ID: From: zerodaysfordays@sdf.lonestar.org (Jakob L. Kreuze) References: <87lfwee2yd.fsf@sdf.lonestar.org> <87h872e2v2.fsf@sdf.lonestar.org> <87ef1yovur.fsf@dustycloud.org> <877e7qvv75.fsf@sdf.lonestar.org> <87a7ckq129.fsf@dustycloud.org> Date: Wed, 07 Aug 2019 16:28:19 -0400 In-Reply-To: (David Thompson's message of "Wed, 7 Aug 2019 15:03:06 -0400") Message-ID: <87sgqclnz0.fsf@sdf.lonestar.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" 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: "Thompson, David" Cc: 36872@debbugs.gnu.org --=-=-= Content-Type: text/plain Hi Chris and Dave, "Thompson, David" writes: > 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? 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 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEa1VJLOiXAjQ2BGSm9Qb9Fp2P2VoFAl1LNGMACgkQ9Qb9Fp2P 2Vqq7A/+IOlyZwgRKkoFCdK0oa/n5cvyxu+1FF3WksiEfKZ4flDF6dojOXq64jVW EutCCflOwOL3cx1QM6wpZ6pN47pvl4IeDUAIickfci9aTlgoZR+dAOCTEfpvP+6t OuxOqN2hurBRW3438U8+ugFlPSwIlW4X31eNFEnG792aivJeAWzLnAZV95iyvzuo CWuQiMWv0/6w0cr/xa6Ec+sf8tLYfsa6y3/A8m0Yf6NDNfznFXyMQ1GTGGX9pp4u 7W/Scser6rQHd7KguKS3BpmoSLwvX+xvdNNPsvJyxqS930iMvbW2fcxaX2ixXcWk xxg7QYPYIkvqW+5r6A+9ggVIae4LWVfryUEYxWjljg9RBec3zo/AHjCliPmmpNVI EHfPv1tKJcL3uIsmam5BMZza0Quvr/A5X3QQ6say/+Bp6/2EVE0WDMeT3vZA3hsn K+yyvZddbSIZ+QCW/GDJpnyJ2tn6H8o4epO88rzqlpIty/uLjoBwfT80Mypo09Xe 8GEdQkghUzkoOIOGbiWVk7jV3DIgzJSFVdh4V1oipxRsAz2zooEzNnF+0Azl1J17 r7k++fZDK0rvrGot6IFjjsPU3SX0mMsURUQhToBxcrfksLLR+0LLDKHrC3oeySez wECacMRSK6zvWM0/fvw5JElQkdwpVfHvgB4n1LeEJW53c09h8eE= =W92O -----END PGP SIGNATURE----- --=-=-=--