[
https://issues.apache.org/jira/browse/JCLOUDS-540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14293266#comment-14293266
]
Ignasi Barrera commented on JCLOUDS-540:
----------------------------------------
This can be controlled by the jclouds location properties when creating the
context, so this issue just makes sense for those providers that dynamically
get the locations. For the major providers, this shouldn't be an issue as the
locations are well-known and preconfigured in jclouds, so I'm changing the
priority to minor as there are already mechanisms to limit the locations in use.
> Allow to list nodes of a concrete Location in the ComputeService
> ----------------------------------------------------------------
>
> Key: JCLOUDS-540
> URL: https://issues.apache.org/jira/browse/JCLOUDS-540
> Project: jclouds
> Issue Type: Improvement
> Components: jclouds-compute
> Affects Versions: 1.7.2
> Reporter: Ignasi Barrera
> Priority: Minor
>
> The ComputeService only offers the following methods to get the information
> of the existing nodes:
> * listNodes
> * listNodesByIds
> * getNodeMetadata
> Those are OK to get all the nodes in all locations, or only certain nodes one
> knows in advance, but are not enough if one wants to work only with a
> concrete location, which can be quite a common use case.
> In cases where the provider disables a location (this happens quite often in
> DigitalOcean depending on their load) or when a region experiences failures
> (this happened in AWS more often than it would be desirable), it could be of
> great help to have a way in the ComputService to scope the operations to a
> concrete location. For example, when a region in AWS fails, right now one
> can't list the nodes in other locations using the ComputeService, and this is
> something that should be fixed.
> Adding the following method should be enough:
> * listNodesInLocation(int locationId)
> But the locationId parameter could also be added to the "runScriptOnNodes" if
> needed. Please, use this issue to discuss the implementation and the scope of
> the changes!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
