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 launch. On Mon, Oct 13, 2014 at 10:02 AM, Chris Dagdigian <dag@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 deployment.

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.

Thanks again!

Regards, Chris