From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Guix "ops" Date: Fri, 01 May 2015 16:48:57 +0200 Message-ID: <87mw1obbfq.fsf@gnu.org> References: <87k2wx6t1e.fsf@fsf.org> <87vbgdy6x8.fsf@gnu.org> <87fv7h5zhk.fsf@fsf.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]:55641) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoCFV-0005Hq-S6 for guix-devel@gnu.org; Fri, 01 May 2015 10:49:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YoCFQ-0003TN-ED for guix-devel@gnu.org; Fri, 01 May 2015 10:49:05 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60968) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoCFQ-0003TJ-Aw for guix-devel@gnu.org; Fri, 01 May 2015 10:49:00 -0400 In-Reply-To: <87fv7h5zhk.fsf@fsf.org> (David Thompson's message of "Thu, 30 Apr 2015 12:53:43 -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-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: David Thompson Cc: guix-devel@gnu.org David Thompson skribis: > 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=98ne= twork.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 seem= s 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. Hmm, I see. > 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. I agree. There must be a way to at least to a one-way mapping from the object to the corresponding key in the cache. >>> * : 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 N= ixOps >> it=E2=80=99s a =E2=80=98deployment=E2=80=99 attribute in the OS attribut= e 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? What about simply ignoring them? =E2=80=98guix system vm=E2=80=99 ignores = the bootloader, for instance, unless it is passed --full-boot. > 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. Sounds good to me. The thing that needs more thought is how to handle things like networking. I guess the tool would need to automatically add, say, a =E2=80=98dhcp-client-service=E2=80=99 to each object, an= d to remove existing services that provide =E2=80=98networking=E2=80=99, and probably f= iddle with other parameters such as the initrd and file systems. (Similar to what =E2=80=98virtualized-operating-system=E2=80=99 does in (gnu system vm).) In effect, one would not be deploying the exact OS that is specified, but rather a variant automatically customized for the deployment target. So probably each object must specified an -> procedure that does this transformation. WDYT? BTW, I=E2=80=99d prefer something like =E2=80=98guix deploy=E2=80=99 over = =E2=80=98guix ops=E2=80=99, but then another name would need to be found for the =E2=80=98deploy=E2=80=99 sub-co= mmand, maybe =E2=80=98realize=E2=80=99? Thanks, Ludo=E2=80=99.