[
https://issues.apache.org/jira/browse/WHIRR-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13124979#comment-13124979
]
David Alves commented on WHIRR-243:
-----------------------------------
So I think an answer to my fork/join question is that this is currently done at
the jclouds level? (1 thread per instance template in whirr side launches
multiple, equal nodes in parallel from jclouds) right?. So how it actually runs
in whirr side is:
fork 1 thread per InstanceTemplate
each run bootstrap script
join threads
main runs config script for all ITs in sequence
So I tried adding some complexity, booting 10 noop+noop3,10 noop2+noop,10
noop3+noop2, but the barrier seems to work nicely.
The bootstrap is done by three different threads in the whirr side, and only
after these complete does the configuration run starts.
Andrei: are you sure this is not a bug in jclouds? couldn't it be the case that
some bootstrap script is reported done while in fact it isn't?
> 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-LogOutput.txt,
> 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