From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Thompson, David" Subject: Re: "guix deploy" is in git master Date: Wed, 10 Jul 2019 09:51:03 -0400 Message-ID: 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: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:58665) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hlD09-0001Oy-V3 for guix-devel@gnu.org; Wed, 10 Jul 2019 09:51:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hlD08-00040u-Uy for guix-devel@gnu.org; Wed, 10 Jul 2019 09:51:17 -0400 Received: from mail-wr1-x430.google.com ([2a00:1450:4864:20::430]:44508) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hlD07-0003xv-P4 for guix-devel@gnu.org; Wed, 10 Jul 2019 09:51:16 -0400 Received: by mail-wr1-x430.google.com with SMTP id p17so2540158wrf.11 for ; Wed, 10 Jul 2019 06:51:15 -0700 (PDT) In-Reply-To: <87lfx8jphz.fsf@elephly.net> 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: Ricardo Wurmus Cc: guix-devel On Mon, Jul 8, 2019 at 3:29 PM Ricardo Wurmus wrote: > > Similarly, it would be great if =E2=80=9Cguix deploy=E2=80=9D would conti= nue deploying > other machines in the list even if one of them couldn=E2=80=99t be deploy= ed due > to an error. I have a list of 24 machines and a few of them fail with > the user-homes error above. Would be nice if all the other deployments > would still go through, because they are independent. Agreed. Also this should be done in parallel eventually because updating 24 machines serially is silly. > (On the other hand, the current behaviour might be desirable in case > there=E2=80=99s a problem with =E2=80=9Cguix deploy=E2=80=9D itself. Rat= her break just one > machine instead of wrecking the whole site. Dunno.) I think we need to make 'guix deploy' robust enough so that we can trust it= . :) 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. 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. 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. :) - Dave