From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Thompson Subject: Re: Guix "ops" Date: Thu, 30 Apr 2015 12:53:43 -0400 Message-ID: <87fv7h5zhk.fsf@fsf.org> References: <87k2wx6t1e.fsf@fsf.org> <87vbgdy6x8.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53071) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YnrvP-0000q2-D3 for guix-devel@gnu.org; Thu, 30 Apr 2015 13:07:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ynrib-00005z-Gw for guix-devel@gnu.org; Thu, 30 Apr 2015 12:53:46 -0400 In-Reply-To: <87vbgdy6x8.fsf@gnu.org> 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-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org Ludovic Court=C3=A8s writes: > David Thompson skribis: > >> * The 'nixops' command is stateful. It stores necessary state about >> deployed systems in a special directory ($HOME/.nixops by default), >> such as the IP addresses of the deployed systems. Because of this, >> each deployment needs a unique identifier. > > Oh, I remember =E2=80=9Ccharon create=E2=80=9D creating this =E2=80=98net= work.json=E2=80=99 file > containing the list of machines and the file names of the Nix expression > used to create that deployment. > > I=E2=80=99m not 100% clear on why this state needs to be stored; it seems= more > like a cache to me, no? That is, Charon/NixOps can always recreate it > from the source Nix expressions. The state that I am concerned with are the details of the resources that have been provisioned by 'guix ops'. For example, in a system that provisions VMs on behalf of the user, the IP address of the machine isn't known until the provisioning has happened. This detail needs to be saved so that 'guix ops' knows how to perform future operations on the machine. Caching the file names of the expressions with a unique key seems hacky to me, and I don't want to copy that without good reason. >> * : Describes a single system in the deployment. Contains a >> name string, an , and a . > > Yes (it=E2=80=99s best to keep it separate from ; in Ni= xOps > it=E2=80=99s a =E2=80=98deployment=E2=80=99 attribute in the OS attribute= set.) Yes, though I do have a question here. Some platforms don't do anything with a bootloader, or in the case of containers (looking towards the future here) the 'kernel' field will be benign as the system shares the kernel of its host. I'm not sure how to deal with this extraneous information. In the case of the 'bootloader', it currently must be specified, so the user would have to input bootloader details that are irrelevant. Thoughts? >> * Use a simple s-exp deployment state format. Store the state in >> $HOME/.config/guix by default. > > Or ~/.cache/guix? Sure, that makes more sense. >> Anyone want to join in on this brainstorming party? Your thoughts are >> appreciated! > > It seems you already have all the requirements and design options > in mind! Thanks, but things are still a bit fuzzy so any design other design considerations are much appreciated. :) So far, I have created the barebones 'guix ops' subcommand and defined the new data types. One can run 'guix ops build deployment.scm' to build all of the machines in a deployment, but no other subcommands have been implemented. For the prototype, I envision 'guix ops deploy local-vm-deployment.scm' to work much like 'guix system vm system.scm', except that it builds and boots multiple VMs. --=20 David Thompson Web Developer - Free Software Foundation - http://fsf.org GPG Key: 0FF1D807 Support the FSF: https://fsf.org/donate