one api, one provider per endpoint, or one provider at all

[Koper, Dies]

I see cloudfiles, cloudloadbalancers, cloudservers, cloudsigma and
elastichosts have a provider directory for each region/data center and
use a single api.
I think the same applies to FGCP so I am following their structure, but
please correct me now if I'm wrong.

FGCP is deployed in six regions (us, uk, de, sg, au, jp), so we have six
endpoints and I can specify only one per ProviderMetadata.
Same for the portal (console).

However, the user certificate contains a region id so a single provider
dynamically picking the correct endpoint is technically feasible for the
FGCP.
Was there a plan to overhaul the provider metadata classes? If so,
please consider this case.

Cheers,
Dies

[Andrei Savu]

Thanks for info! I agree with you that ProvideMetadata needs to be more flexible to be able to 

describe multiple regions / deployments. How do you think that interface should look like?

I think this is the right approach in your case to have a common API implementation 

and multiple providers, one for each region. 

Cheers,

-- Andrei Savu / andreisavu.ro

--
You received this message because you are subscribed to the Google Groups "jclouds-dev" group.
To post to this group, send email to jclou...@googlegroups.com.
To unsubscribe from this group, send email to jclouds-dev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jclouds-dev?hl=en.

[Adrian Cole]

Hi, Dies.

Currently, ProviderMetadata (which yes, does need an overhaul)
contains a list of isocodes relating to the regions on a service. We
designate a single provider more about the account scope, so, for
example, if your account scope is across multiple regions, it should
be in one provider.

There are current means to set the zones of a provider using the
*PropertiesBuilder class.

Basically, you set jclouds.zones property to a comma-separated list of
zone ids and then for each, the following accordingly
jclouds.(zoneid).endpoint
jclouds.(zoneid).iso3166

it is the same as AWSS3PropertiesBuilder, except s/region/zone

Now, the tricky thing is that you mention there is a certificate per
zone? If this is the case, this implies something the model doesn't
yet work with, which is an identity that changes per-zone. If it is
indeed the case that there's a 1-1 mapping of certificate to zone,
then I'd make them separate providers for now.

We can always refactor and join them later (as proof that a new
provider model sticks)

Cheers,
-A

On Tue, Feb 28, 2012 at 5:05 AM, Koper, Dies <di...@fast.au.fujitsu.com> wrote: