incubator-deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Lutterkort <lut...@redhat.com>
Subject Re: [PATCH core 2/2] Keypair managment for EC2 driver
Date Wed, 28 Jul 2010 22:40:30 GMT
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



Mime
View raw message