Thanks Chris, it's great to hear that Cloudman worked well for you!
There actually is a way to launch an instance providing a share-a-cluster
string in user data for a while, (a `share_string: <stuff>` entry in user
data) but there is, or was -- I need to test this again, a race condition
in the boot logic that would sometimes have the instance go belly up on
On Mon, Oct 13, 2014 at 10:02 AM, Chris Dagdigian <dag(a)sonsorol.org> wrote:
Wanted to send Dannon & the list a quick note of thanks.
Cloudman-managed Galaxy is pretty slick. I'm using it today to run 26
individual Galaxy instances running on big c3.8xlarge AWS nodes for a
training class. Each of the 26 training systems is built from a shared
cluster string config which means I can stand up tested systems that
also contain a "hidden" history that students can access and refer to if
they get stuck.
We wanted to give each student their own individual Galaxy sandbox to
play on and Cloudman made it very easy. Faster than custom configuring a
personal AMI and using Chef/devOps tricks to clone and automate the
All told it took me about 1.5 days to get my head around cloudman and
make all the usual mistakes regarding breaking things, screwing things
up and otherwise running through the learning curve. After that it took
me about 1 day to load the master cluster image up with data, history
and run through all of the lab exercises. After that it was about 2
hours to share the cluster and start firing up the clones
One thing that would help (and perhaps this is something that I missed
in the documentation) would be the ability to pass in the shared cluster
string as user-data at launch time. That would have let me fire up the
training nodes with a single shell script. Instead I used a shell script
to fire up the nodes but then I had to hit the cloudman URL on each node
to punch in the shared-cluster URI string.