From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Meyer Subject: [Mark Meyer] Re: AWS + OpenStack support Date: Tue, 11 Apr 2017 07:48:00 +0200 Message-ID: <871sszh4vj.fsf@ofosos.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:33467) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cxoes-0007Vb-Dh for guix-devel@gnu.org; Tue, 11 Apr 2017 01:48:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cxoep-0002ov-8J for guix-devel@gnu.org; Tue, 11 Apr 2017 01:48:06 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:52104) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cxoep-0002oj-2c for guix-devel@gnu.org; Tue, 11 Apr 2017 01:48:03 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 4A68620B16 for ; Tue, 11 Apr 2017 01:48:02 -0400 (EDT) Received: from pericles (x55b3b1ef.dyn.telefonica.de [85.179.177.239]) by mail.messagingengine.com (Postfix) with ESMTPA id BE5A37E2B1 for ; Tue, 11 Apr 2017 01:48:01 -0400 (EDT) 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: guix-devel@gnu.org --=-=-= Content-Type: text/plain Sorry, didn't go to the list. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline X-From-Line: nobody Tue Apr 11 07:45:10 2017 From: Mark Meyer To: Chris Marusich Subject: Re: AWS + OpenStack support References: <87lgr8hv48.fsf@ofosos.org> <874lxvo9yv.fsf@gmail.com> X-Draft-From: ("INBOX" 6541) Date: Tue, 11 Apr 2017 07:45:08 +0200 In-Reply-To: <874lxvo9yv.fsf@gmail.com> (Chris Marusich's message of "Mon, 10 Apr 2017 21:16:08 -0700") Message-ID: <878tn7h50b.fsf@ofosos.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Lines: 63 Xref: pericles sent.2017-04:3 MIME-Version: 1.0 Content-Type: text/plain >>>>> "Chris" == Chris Marusich writes: Chris> Mark Meyer writes: Chris> I think it'd be awesome if this were easier to do! This Chris> topic has come up before: Chris> https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00757.html Chris> https://lists.gnu.org/archive/html/help-guix/2016-11/msg00075.html Ah. I completely missed the latter discussion. Chris> Long story short, instead of starting with a base image and Chris> modifying it (e.g., by injecting credentials at first boot Chris> via the EC2 metadata service), one appealing alternative is Chris> to use EC2's VM import feature to actually import precisely Chris> the system that you want to launch: Chris> https://aws.amazon.com/ec2/vm-import/ Which does not work with GuixSD (tried it). Apparently it looks into the image an expects stuff like fstab. I find it not very trust building that it actually inspects the image. Chris> Customizations, such as SSH credentials, would be specified Chris> in a GuixSD operating system configuration file and built Chris> into the VM image, so neither the EC2 metadata service, nor Chris> hacks like the "cloud-init" script used by some distros, Chris> would enter into the picture at all. Chris> Some preliminary work in a similar spirit was already done in Chris> the branch 'wip-deploy', but I don't think it was Chris> EC2-specific in any way. Perhaps by looking there, you can Chris> find some inspiration? Here the immediate downside would be that stuff like auto-scaling does not work out of the box. Which some people consider one of the selling features of AWS, the prices for VM hosting being rather high. Chris> I think it would be better to spend your energy on creating a Chris> mechanism that allows an individual to build a GuixSD image Chris> from their own operating system configuration file, import Chris> that into EC2, and then launch an instance from it. If such Chris> a feature were available in GuixSD, you could do it once from Chris> a desktop/laptop with a slow internet connection to create a Chris> "control server" in the cloud (with a fast internet Chris> connection), and then you could run it from the control Chris> server as needed to quickly spin up whatever other instances Chris> you might need. I think the above steps could be shortened somewhat and automated, if you know you're running on ec2. I don't see a way to cleanly import an image into AWS. This is however different for OpenStack, there you have an image service that does just what we need. I'll try my hand at optimizing these steps on the weekend. Cheer, Mark -- Mark Meyer mark@ofosos.org --=-=-= Content-Type: text/plain -- Mark Meyer mark@ofosos.org --=-=-=--