From mboxrd@z Thu Jan 1 00:00:00 1970 From: zerodaysfordays@sdf.lonestar.org (Jakob L. Kreuze) Subject: Re: "guix deploy" is in git master Date: Wed, 10 Jul 2019 13:39:22 -0400 Message-ID: <87sgrd6b79.fsf@sdf.lonestar.org> References: <87a7drn0ux.fsf@dustycloud.org> <874l3zse7o.fsf@elephly.net> <87wogujmld.fsf@elephly.net> <871rz19a4h.fsf@gnu.org> <87r270ig1d.fsf@sdf.lonestar.org> <87lfx8jphz.fsf@elephly.net> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:53386) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hlGZF-0004zz-JT for guix-devel@gnu.org; Wed, 10 Jul 2019 13:39:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hlGZC-0003WW-NR for guix-devel@gnu.org; Wed, 10 Jul 2019 13:39:44 -0400 Received: from mx.sdf.org ([205.166.94.20]:59500) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hlGZA-0003NP-8N for guix-devel@gnu.org; Wed, 10 Jul 2019 13:39:40 -0400 In-Reply-To: (David Thompson's message of "Wed, 10 Jul 2019 09:51:03 -0400") 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 --=-=-= Content-Type: text/plain Hi Dave, "Thompson, David" writes: > Agreed. Also this should be done in parallel eventually because > updating 24 machines serially is silly. Good idea. Do we have a Guix-specific API for parallelism, or should I look to the Guile manual section on Futures? > This does bring up the question of what to do upon failure. Other > deployment systems that I've worked with (mainly AWS CodeDeploy) > provide some options. First, the user can specify what it means for a > deploy to succeed. Does it have to successfully deploy to each of them > or should it allow some amount of failure? Then, upon failure, the > user can specify whether or not a rollback should happen. Would it make sense to allow failure to be defined on a machine-by-machine basis? For example, adding some sort of 'behavior-on-failure' field to the 'machine' type? Other options that come to mind are a '--behavior-on-failure' option for 'guix deploy', or to use a more elaborate type for deployment specifications, maybe having a 'machines->deployment' function, similar to 'packages->manifest'. > My personal preference for default behavior right now is to update > everything possible and print out a report so users can see what > failed, but I think ultimately we'll need to provide more options. Agreed. > We need to also keep in mind that in-place updates to machines is just > a primitive initial use-case. Things will get really fun when we get > to blue-green deployments in cloud environments because "rollback" > takes on a whole new meaning. :) Glad to hear that you're already thinking about this sort of thing :) Regards, Jakob --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEa1VJLOiXAjQ2BGSm9Qb9Fp2P2VoFAl0mIsoACgkQ9Qb9Fp2P 2VrfoQ/8DTAuPpdEjzaPf3UjkxK4v03FUFyUpsLYLWkqkSN/Nr/2TdBXb2SjYezb Lwhk4nsMDU9oztR9Hcinp+U+BzNHx2h0jykaQtGLsK5SVuZJpguZRXCYBe4rn27G lXZlz73H7vUZuLww1/rPn5Mi29Qt+MPC9qVuIv0UDTvGARGrrRCnxuFltIr3D3+A ZO38JHZWpsfVpPgQAFpXLEbGMTz8xTS2UWaerO3cS+bdFsLrSa/ePSlUSm/o2uId KkIWZ9g053iEwm1oJzpH8D1Yy+3Nzu60rO1e5Fyoe3aXrwoLHHWYeGFPGOkhZz0j 9HCwTrJhQ5Qia51/Sw1a3GKwoSCMRlQiRLm33JmrTKsvex057tq0zA4K96v2NHzC 3aaRHqowmiF50a+O0eWhylBqJm/QfYsWzPktiIjCpd5QKsZS3fgdg07EIBel/IBO S6amvrqM6eDqxEniT2OQETX4188mIUJTHvVOk8Y0o0Y1I38RIboTzJRvASuOUTwD cMR1XznnONSIBiHtUBujT6mGXBGJvVXTGOw+Cmde2jJEOIOdCEnsC6sHOnX188+V Qe7V4xzIYhrdInr09dDw2eM6M3AzbOJRNu14xpnvcWTLAqi6KpuZZkEpzeb19kPf Gv0TcMhSPMu0BDMW1kv7kvF9tQAubWzpokQk9pVCT4+VbA80CX8= =31db -----END PGP SIGNATURE----- --=-=-=--