On Wed, 2011-06-08 at 16:11 +0100, Mark McLoughlin wrote:
1) We should move to using a single instance of deltacloud
You can not assume that you will only ever have to talk to one
deltacloud server - that is possible right now; but this may change in
the future with more support for RHEV-M, vSphere, and Falcon. The
drivers for these all have their own preference for running 'close' to
their backends and it might therefore be necessary to have separate
deltacloud servers for them.
5) Image factory should use the provider/driver details from the
deltacloud API, once some more details are exposed
What is the add'l detail that should be exposed there ?
- deltacloud knows about all EC2 regions and automatically exposes a
provider for each one. See the /api/drivers collection and the
configuration in drivers.yaml describing each region/provider
/api/drivers tells you about what that server knows about and can talk
to - that does not mean that all Deltacloud servers will give you the
exact same info for /api/drivers. Falcon, e.g., should only list one
driver there, for Falcon.
- Where deltacloud/conductor doesn't know anything about your
RHEV-M
or VMWare instance, you can just enter its URL
I would expect, that in the long run, the URL of the RHEV-M/vSphere
backend will need to be configured as part of setting up deltacloudd;
there are various things that may (or not) need to be added to those
drivers that will make that necessary.
For example, for RHEV-M 2.2, it looks like the only way to inject data
into a VM is to copy the image, frob it, then upload it back to RHEV-M.
If we really have to implement that, the URL for the RHEV-M API will
become part of the deltacloudd installation, and not be changeable by
the API user.
Work needed:
- It would be nice to see the provider details in the /api/drivers
listing - e.g. the RHEV-M URLs, the EC2 endpoints etc.
Why should we list the EC2 endpoints ? And which ones ? Even for one
region, we talk to three different endpoints (S3, EC2, LB)
- A simple change is needed to support having multiple RHEV-M URLs
in
drivers.yaml and exposing them as different providers
The more I think about it, the more I start thinking that passing in
URL's as the provider is a bug not a feature, at least for RHEV-M,
Falcon, and vSphere. For Euca it's nice and convenient (and right), but
as soon as the driver need a special connection to its backend, there's
no way that just a URL is enough to select a provider.
- The driver= and provider= matrix params need to be URI encoded so
that we can pass a RHEV-M URL using the param
They are not ? Definitely a bug.
David