From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= Subject: Re: Thoughts on stateful services in Guix Date: Wed, 05 Feb 2020 15:04:12 +0100 Message-ID: <87a75xp1ur.fsf@gnu.org> References: <87r1zexcu3.fsf@gmail.com> 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]:33655) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1izLHt-0004bN-6Y for guix-devel@gnu.org; Wed, 05 Feb 2020 09:04:18 -0500 In-Reply-To: <87r1zexcu3.fsf@gmail.com> (Alex Sassmannshausen's message of "Sat, 01 Feb 2020 21:38:28 +0100") 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-mx.org@gnu.org Sender: "Guix-devel" To: Alex Sassmannshausen Cc: Guix-devel Hi Alex, Thanks for sharing your thoughts and this tricky but important use case! Alex Sassmannshausen skribis: > 3 A generalisation: the Stateful-Service Service > =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90 > > State dumping and restoration *should* be generalisable. > > It should normally consist of one or more operations of: > =E2=80=A2 running a special program to dump data, encrypting the dump, = and > storing it, together with the service revision hash, in a known > location. > =E2=80=A2 tarring up a directory tree, encrypting the archive and stori= ng it, > together wtih the service revision hash, in a known location. > > These operations should be able to be provided by a daemon, managed by > shepherd, which can be configured with a gpg key for encryption, a > mechanism for decryption (interactive or programmatic), a location for > storing/retrieving dumps (local or remote?), and a DSL for mapping > data dump / data restoration program invocations or file-system > locations to data dumps it already knows of. Back in my Nix days, Wouter den Breejen worked on =E2=80=9CS-Nix=E2=80=9D, = whose goal was to explore how Nix could be extended to support state=C2=B9. Back then, I think the experiment was not considered fruitful, in part due to its complexity, the implementation=E2=80=99s reliance on ext3cow, things like t= hat. There may still be good ideas to take from that, although it=E2=80=99s prob= ably more reasonable to start with something simple and practical, trying to address a couple of concrete use cases before trying to generalize. What you propose above sounds like it could be a good start! Ludo=E2=80=99. =C2=B9 =E2=80=9CManaging state in a purely functional deployment model=E2= =80=9D, master thesis, . I couldn=E2=80=99t find a copy on-line so here=E2=80=99s one from my atti= c: .