[
https://issues.apache.org/jira/browse/WHIRR-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13124314#comment-13124314
]
David Alves commented on WHIRR-243:
-----------------------------------
If the problem is precisely that running a bootstrap script returns as
completed while in fact it is not, then you're right but that is a jclouds
specific issue right (meaning we shouldn't even need to test it).
Still I have a question, let's say I build a cluster as such:
{code}
CompositeConfiguration config = new CompositeConfiguration();
config.setProperty("whirr.provider", "stub");
config.setProperty("whirr.cluster-name", "stub-test");
config.setProperty("whirr.instance-templates", "10 noop");
ClusterSpec clusterSpec = ClusterSpec.withTemporaryKeys(config);
ClusterController controller = new ClusterController();
controller.launchCluster(clusterSpec);
{code}
Launching such a cluster should happen in parallel right, with a barrier
between phases?
in pseudo-code:
fork 10 threads
each run bootstrap script
join 10 threads
fork 10 threads
each run config script
join 10 threads
But when I launch the cluster I just introduced, I get a nice interleaved
output, where all the initscripts are executed by a thread in a thread pool and
all the config scripts are executed by main (like the attached log output
illustrates). Is this supposed to happen?
> 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-only-LogDryRunModule.patch, WHIRR-243.patch,
> WHIRR-243.patch, WHIRR-243.patch, WHIRR-243.patch, WHIRR-243.patch,
> WHIRR-243.patch, 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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
