From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marius Bakke Subject: Scope of "GuixOps" (was Re: [ANNOUNCE] ganeti-instance-guix) Date: Wed, 20 Sep 2017 21:44:37 +0200 Message-ID: <871sn1b1ei.fsf@fastmail.com> References: <87poapatfo.fsf@fastmail.com> <874ls0qvoj.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35538) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dukvM-0003Dk-T5 for guix-devel@gnu.org; Wed, 20 Sep 2017 15:44:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dukvI-0003bP-LN for guix-devel@gnu.org; Wed, 20 Sep 2017 15:44:44 -0400 In-Reply-To: <874ls0qvoj.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" To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ludovic Court=C3=A8s writes: > Hi! > > [- ganeti] > > Marius Bakke skribis: > >> When you want to try GuixSD, but all you have is a Ganeti cluster... >> >> I'm pleased to announce ganeti-instance-guix[0], a GuixSD provisioner >> for Ganeti. With it you can launch any GuixSD configuration file as >> a virtual machine, optionally using a specific Guix git revision. > > That looks nice! Thanks! Longer term I intend to create a Guix-centric web frontend for Ganeti similar to . Stay tuned! > I wonder what we could do longer-term to simplify provisioning of GuixSD > VMs/containers managed by other tools. Perhaps that=E2=80=99s a job for > =E2=80=9CGuixOps=E2=80=9D? What=E2=80=99s your take on this? For integration with common "cloud" providers (Openstack, AWS, etc), it would be great to create a VM (or disk) image that does this on boot: 1) Resize partition to use whole disk. 2) Reconfigure/init from a configuration file URL, typically a provider-specific method of providing metadata to VM. 3) Possibly runs `guix pull` against some similar metadata parameters. Then Guix could conceivably be supported by other provisioning tools that works with such systems (Terraform etc). This would also go a long way towards PXE booting... I haven't really given "GuixOps" a lot of thought until now, but I imagine a more low-level administration tool along the lines of... $ guix machine --add htpc htpc.local $ guix machine htpc reconfigure ~/dotfiles/guixsd/xbmc.scm $ guix machine htpc reboot "reconfigure" here would build the system locally and send over the closure, so that the remote system never needs to `guix pull`. For provisioning, maybe something like... $ guix provision --provider pxe ceph-osd{1..21} $ guix provision --provider ganeti guixbuilder{1..4} would adjust hostname and IP addresses according to some criteria and register the machines. This is loosely inspired by xCAT and would require a stateful database. Now I'm getting carried away: $ guix machine --edit r2d2 --ipmi admin@192.168.13.2:password $ guix machine r2d2 console (SOL) $ guix machine r2d2 powercycle (IPMI/API) Arguably some of this falls well outside the scope of Guix, but I do think there is room for an all-round systems management solution. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAlnCxSUACgkQoqBt8qM6 VPqKWQgAoGnsIK27QQy4zBAdYHbvVR8iL/Ll0+uxq6H79xzVF62JPPYyvn1OENh3 r2Urf1jSdAjDYwIif8P94NY7XqaBCHIvN+bqjLN9+Rz4Xz37VwNlQSCrPuiAtkRv 7k1w5XcwI6p61e/QK20boBToeZ0Aen+2oin9fn4vWWfT7GhtsEpqtIg98GzWnMFb xdsj+j0pqg2S2j4fZysW4w2FUAfMEG9sF4Kl2+ditLC0VCAubBw896C6nHr1sqpc kFbLIIWAD/wohBIzlXV1txXMjdC/9UsejtECYoBPLq3jYbcazCe1kadgCFb/228G lbeigDkx//0x4kKVyBBUBVyLK5V9Ow== =TWCl -----END PGP SIGNATURE----- --=-=-=--