gatj98 commented on this pull request.
> +
+import com.google.common.base.Supplier;
+import org.jclouds.http.HttpException;
+import org.jclouds.http.HttpRequest;
+import org.jclouds.http.HttpRequestFilter;
+import org.jclouds.location.Zone;
+
+import javax.inject.Inject;
+import java.util.Set;
+
+/**
+ * Adds set of Datacenter IDs as set in jclouds.zones JVM property.
+ */
+public class DatacenterIdListDatacentersFilter implements HttpRequestFilter {
+ @Inject
+ @Zone
Good Q - we were having a discussion about this ourselves the other day. Your
input would be appreciated @nacx!
DD has a number of 'Geos', each has it's own cloud control API endpoint, and
consists of 1 or more datacenters. At present we see our provider as being for
a single Geo (as it's the simplest thing to do to start with), but maybe we
should aim to have a single provider to cover them all in time. There is no
global API endpoint, so when creating a compute service instance we'd have to
call out to multiple Geos to find out where the user is based (their home Geo)
and which 'shaddow' Geos they also have access to. We do have an API that can
be called on any Geo to find a users home Geo that does this fan-out, but I'm
not sure if it's publicly published or not.
Anyway, to answer your Q I think the mapping should be:
Region -> Geo (only 1 for now - we prob need to do something to model this?)
Zone -> Datacenter
Does that sound ok?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/377#discussion_r108029942
