[
https://issues.apache.org/jira/browse/JCLOUDS-540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13977245#comment-13977245
]
Ignasi Barrera commented on JCLOUDS-540:
----------------------------------------
Agree in everything.
And I'll open an improvement to change the return type of the listNodes to
NodeMetadata. I don't know either why it returns the superclass (and it is
indeed annoying), but AFAIK there only exists one implementation, so I'm pretty
sure that we'll be able to change that with little impact.
> 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
> Assignee: Ignasi Barrera
> Fix For: 1.8.0
>
>
> 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.2#6252)
