From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= Subject: Re: building "guix deploy" Date: Sun, 10 Mar 2019 18:42:33 +0100 Message-ID: <87h8ca1v92.fsf@gnu.org> References: <87k2wx6t1e.fsf@fsf.org> <87h8da5u5k.fsf@dustycloud.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([209.51.188.92]:34406) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h32T7-0001xf-Um for guix-devel@gnu.org; Sun, 10 Mar 2019 13:42:38 -0400 In-Reply-To: (David Thompson's message of "Sat, 9 Mar 2019 23:29:04 +0000") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: "Thompson, David" Cc: guix-devel Hi there! "Thompson, David" skribis: > Chris Webber and I spent the morning chatting about how we want to > approach making "guix deploy" a reality and then started hacking on it > in the afternoon. Although we weren't able to complete a working > prototype by the end of the day, we were able to get pretty close. We > created a 'guix deploy' CLI to build derivations for any number of > remote systems on a local workstation and initiate the transfer to the > remote systems, but we encountered a difficult to debug SSH error that > blocked our progress: > > sending 85 store items (0 MiB) to 'test.activitypub.rocks'... > exporting path `/gnu/store/ylcdmrj3vf00ixdcjvkl3mbs8f5i9w8l-git-minimal-2= .20.1.drv' > ;;; [2019/03/09 17:32:48.792589, 0] write_to_channel_port: [GSSH > ERROR] Remote channel is closed: # 541a220> > Backtrace: > 10 (apply-smob/1 #) > In ice-9/boot-9.scm: > 705:2 9 (call-with-prompt _ _ #) > In ice-9/eval.scm: > 619:8 8 (_ #(#(#))) > In guix/ui.scm: > 1654:12 7 (run-guix-command _ . _) > In guix/scripts/deploy.scm: > 72:8 6 (guix-deploy . _) > In srfi/srfi-1.scm: > 640:9 5 (for-each # =E2=80=A6) > In guix/scripts/deploy.scm: > 74:20 4 (_ _) > In gnu/machine.scm: > 58:22 3 (_ _ _ _) > In guix/ssh.scm: > 313:4 2 (send-files # _ _ # _ # =E2= =80=A6) > In guix/store.scm: > 1504:7 1 (export-paths # _ # =E2=80=A6) > In unknown file: > 0 (put-bytevector # =E2= =80=A6) > > ERROR: In procedure put-bytevector: > Throw to key `guile-ssh-error' with args `("write_to_channel_port" > "Remote channel is closed" # > #f)'. > > If anyone knows what might be going on here and how we could resolve > it, your input would be much appreciated! We verified via the sshd > logs that we were indeed successfully establishing a connection. Error reporting in (guix ssh) is, ahem, not as good as it could be. Apparently the SSH channel was closed prematurely, which could be due to a number of things: 1. Are =E2=80=98guix=E2=80=99 and =E2=80=98guile=E2=80=99 in $PATH on the= remote machine, for non-interactive shells? 2. Is =E2=80=98guix repl=E2=80=99 available in the remote machine? You can test this with: ssh HOST guile --version ssh HOST guix repl --version Also, does =E2=80=98guix copy=E2=80=99 fail similarly when sending files to= that host? > Once we're past this blocking issue and are able to transfer OS > closures to remote systems, we plan to write a modified version of > switch-to-system that uses guile-ssh to switch remote symlinks for the > active system and run the activation script. We'll save > upgrade-shepherd-services for later, as it is quite a bit more > complex. My plan is to have =E2=80=98guix system reconfigure --host=3Dhost.example.o= rg=E2=80=99. To do that, I thought about the following plan: 1. Isolate the effectful part of reconfigure (basically =E2=80=98switch-to-system=E2=80=99). 2. Implement =E2=80=98remote-eval=E2=80=99, which takes a gexp and an SSH= session and evaluates the expression remotely, copying the gexp inputs as needed. 3. Have =E2=80=98reconfigure=E2=80=99 use either =E2=80=98eval=E2=80=99 o= r =E2=80=98remote-eval=E2=80=99 to evaluate the effectful bits of reconfigure. #1 is a bit annoying because we need to untangle code so that we can easily put it all =E2=80=9Con the build side.=E2=80=9D In particular, I th= ink we=E2=80=99ll have to change (guix graph), used by =E2=80=98upgrade-shepherd-services=E2= =80=99, so that it no longer depends on =E2=80=98%store-monad=E2=80=99. That said, it=E2=80=99s probably a good idea to take a shorter path in the meantime to unlock progress on =E2=80=98guix deploy=E2=80=99! > There's not a lot of code yet, but you can check it out in the > wip-deploy2 branch. Currently, the only supported use-case is running > the equivalent of 'guix system reconfigure' on machines already > running GuixSD that have an OpenSSH daemon running, but the basic > design allows for additional use-cases to be supported in the future. Yay! Thank you gentlefolks for resuming work on this! Ludo=E2=80=99.