Return-Path: Delivered-To: apmail-incubator-deltacloud-dev-archive@minotaur.apache.org Received: (qmail 85506 invoked from network); 28 Jul 2010 22:40:58 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 28 Jul 2010 22:40:58 -0000 Received: (qmail 70428 invoked by uid 500); 28 Jul 2010 22:40:58 -0000 Delivered-To: apmail-incubator-deltacloud-dev-archive@incubator.apache.org Received: (qmail 70400 invoked by uid 500); 28 Jul 2010 22:40:58 -0000 Mailing-List: contact deltacloud-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: deltacloud-dev@incubator.apache.org Delivered-To: mailing list deltacloud-dev@incubator.apache.org Received: (qmail 70392 invoked by uid 99); 28 Jul 2010 22:40:58 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Jul 2010 22:40:58 +0000 X-ASF-Spam-Status: No, hits=-5.0 required=10.0 tests=RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of lutter@redhat.com designates 209.132.183.28 as permitted sender) Received: from [209.132.183.28] (HELO mx1.redhat.com) (209.132.183.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Jul 2010 22:40:52 +0000 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o6SMeVnI000778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 28 Jul 2010 18:40:31 -0400 Received: from [10.3.113.13] ([10.3.113.13]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o6SMeUZS016645 for ; Wed, 28 Jul 2010 18:40:30 -0400 Subject: Re: [PATCH core 2/2] Keypair managment for EC2 driver From: David Lutterkort To: deltacloud-dev@incubator.apache.org In-Reply-To: <1280320779-31659-3-git-send-email-mfojtik@redhat.com> References: <1280320779-31659-1-git-send-email-mfojtik@redhat.com> <1280320779-31659-3-git-send-email-mfojtik@redhat.com> Content-Type: text/plain; charset="ISO-8859-15" Organization: Red Hat Inc Date: Wed, 28 Jul 2010 15:40:30 -0700 Message-ID: <1280356830.4000.45.camel@avon.watzmann.net> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.21 On Wed, 2010-07-28 at 14:39 +0200, mfojtik@redhat.com wrote: > --- > server/lib/deltacloud/drivers/ec2/ec2_driver.rb | 119 ++++++++++++++++++++ > server/lib/deltacloud/drivers/ec2/keypair.rb | 24 ++++ > .../lib/deltacloud/helpers/application_helper.rb | 6 + > server/views/keypairs/index.html.haml | 21 ++++ > server/views/keypairs/index.xml.haml | 4 + > server/views/keypairs/new.html.haml | 8 ++ > server/views/keypairs/show.html.haml | 12 ++ > server/views/keypairs/show.xml.haml | 11 ++ > 8 files changed, 205 insertions(+), 0 deletions(-) > create mode 100644 server/lib/deltacloud/drivers/ec2/keypair.rb > create mode 100644 server/views/keypairs/index.html.haml > create mode 100644 server/views/keypairs/index.xml.haml > create mode 100644 server/views/keypairs/new.html.haml > create mode 100644 server/views/keypairs/show.html.haml > create mode 100644 server/views/keypairs/show.xml.haml NAK. There's two things that merit more discussion in this patch: * By storing the PEM in the filesystem, the server is now stateful; in addition, users will get different responses, depending on whether they created the key with this very Deltacloud instance, or another one, or by some other means. I know it sucks that we can only provide the PEM on key creation, but that's how EC2 does it. * The operations for the keypairs collection shouldn't go into the EC2 driver; instead, they should go into server.rb. As an aside, since it keeps coming up: one of the big hesitations about making the server stateful is that it will make it much harder to move from one Deltacloud instance to another, and that you'll have to start backing up things etc. It would be interesting to think about federating Deltacloud Server instances, with the intent to avoid all the hassles of switching between stateful servers, handling backups etc. One idea is to use a distributed data store for this, e.g., couchdb or mongodb (we'd have to look in detail at our needs to find the approriate one) I think sooner or later, we also need to have a way for different Deltacloud servers to talk to each other and report a list of servers around them, so that I can go to the one server I know about and get a list of other servers (possibly running different drivers) from it. David