nacx 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
Makes sense. In that case, take into account that the default Region/Zone
suppliers (those bound with the `@Region` and `@Zone` qualifiers) take the
values from configuration properties (as in
[ProfitBricks](https://github.com/jclouds/jclouds/blob/master/providers/profitbricks/src/main/java/org/jclouds/profitbricks/ProfitBricksProviderMetadata.java#L64-L74).
In this case, I think it would make sense to configure all the regions via
properties (including their endpoints with the
`jclouds.region.<regionname>.endpoint` property) and then bind specific Zone
suppliers to get them using the API, as done in
[EC2](https://github.com/jclouds/jclouds/blob/master/apis/ec2/src/main/java/org/jclouds/ec2/config/BaseEC2HttpApiModule.java#L53-L57).
WDYT?
--
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_r108097826
