On 28/07/10 15:40 -0700, David Lutterkort wrote:
On Wed, 2010-07-28 at 14:39 +0200, [email protected] 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.
Yes, thats a good argument. I see some options here, like not storing
PEM keys and just return it when new keypair is created. Something like we
do with Rackspace passwords. So client will have chance to save it/manage
it.
* The operations for the keypairs collection shouldn't go into the
EC2 driver; instead, they should go into server.rb.
Sure. I throught that this collection is EC2 specific, so I should go to
ec2 driver directly. After this I realized, that this can create a
'precendes' to put different things into drivers. So I can move keypair
managment to server and exclude it from 'default collections' and enable it
for EC2 only.
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.
Agree.
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)
Yes, couchdb sounds great. Anyway you will still need to handle
synchronization between deltacloud server instances / locks / etc.
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.
Are you talking about some 'lighweight' aggregator/proxy for 'core' ?
-- Michal
--
--------------------------------------------------------
Michal Fojtik, [email protected], +420 532 294 4307
Ruby / Ruby On Rails Developer
Deltacloud API: http://deltacloud.org
--------------------------------------------------------
