[jira] Issue Comment Edited: (WHIRR-243) Allow to run component tests in memory

["David Alves (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/WHIRR-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13000826#comment-13000826 ] 

David Alves edited comment on WHIRR-243 at 3/1/11 11:07 AM:
------------------------------------------------------------

Adrien

I applied your patch and even though now I can see that the nodes start in the expected order in the logs, its hard to make assertions on this starting order. The previous patch maintained state on which nodes were started at which time. (grouped them in runs one for each instance template). How can this be done now?

Reading/writing cluster state is a feature I also require for WHIRR-214, and Tom suggested that this could be done by reading the "~/.whirr/cluster-name/instances" file. On the other hand you suggested that cluster state could also be written/read to/from the cluster itself. Maybe we should create a more permanent way to read/write cluster state that could start by using the instances file and alternatively use the cluster itself, as you also suggested (if the cluster is to be responsible for its own scaling up/down ops. state must be stored there).

      was (Author: dr-alves):
    Adrien

I applied your patch and even though now I can see that the nodes start in the expected order in the logs, its hard to make assertions on this starting order. The previous maintained state on which nodes were started at which time. (grouped them in runs one for each instance template). How can this be done now?

Reading/writing cluster state is a feature I also require for WHIRR-214, and Tom suggested that this could be done by reading the "~/.whirr/cluster-name/instances" file. On the other hand you suggested that cluster state could also be written/read to/from the cluster itself. Maybe we should create a more permanent way to read/write cluster state that could start by using the instances file and alternatively use the cluster itself, as you also suggested (if the cluster is to be responsible for its own scaling up/down ops. state must be stored there).
  
> Allow to run component tests in memory
> --------------------------------------
>
>                 Key: WHIRR-243
>                 URL: https://issues.apache.org/jira/browse/WHIRR-243
>             Project: Whirr
>          Issue Type: Improvement
>          Components: core
>            Reporter: David Alves
>            Assignee: Adrian Cole
>            Priority: Minor
>         Attachments: WHIRR-243.patch, WHIRR-243.patch
>
>
> While jclouds now features the awesome BYON mode it might be useful to be able to run compoenent and systems tests without jclouds.
> I tried jclouds stub features but unless I'm missing something (I might) there is no way of stubbing a compute service that allows to call runOnNodesMatching.
> So my idea is to alter ComputeServiceContextBuilder a bit to account for a new provider ("test") in which case an instance of a StubComputeServiceContext is returned (which features a StubComputeService internal class). This allows to make assertion regarding which nodes were started or not and on which order, which I think is useful.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira