Fantastic approach! Different context, same suggestion, lets merge our effort :). In our Cloud environment I am extracting RAW files in a wine environment (1,2), in a more traditional cluster environment the same wrapper can run under Windows using the LWR (3). I have not really developed the LWR cloud picture yet so your approach is really exciting, what I would recommend is that you build your msconvert wrapper logic into the galaxyp msconvert wrapper (4) and dispatch based on the environment. It looks like you are hardcoding your AMI name for instance, what we could do is fetch that from the environment and if it is available use your stuff: def main(): # build up parameters, etc... if "WINDOWS_GALAXY_AMI" in os.environ: adapt_ec2_logic() else: run_local() That way we will have a unified interface for the users (workflows can be shared regardless of how the tools are executed) and the many different deployment options. I can get around the legal ambiguities of distributing wine environments packaged .NET by using your stuff when sharing on EC2 and people that want to use adapt outside of EC2 can use the LWR or wine. If your are interested e-mail me directly and I will give you access to the repository and we can talk about other specific changes to the wrapper you may want to make. 1: https://github.com/jmchilton/proteomics-wine-env 2: https://github.com/jmchilton/cloudbiolinux/tree/proteomics-wine 3: http://wiki.g2.bx.psu.edu/Admin/Config/LWR 4: https://bitbucket.org/galaxyp/galaxyp-toolshed-msconvert -John ------------------------------------------------ John Chilton Senior Software Developer University of Minnesota Supercomputing Institute Office: 612-625-0917 Cell: 612-226-9223 Bitbucket: https://bitbucket.org/jmchilton Github: https://github.com/jmchilton Web: http://jmchilton.net On Fri, Oct 19, 2012 at 4:57 AM, Jorrit Boekel <jorrit.boekel@scilifelab.se> wrote:

Dear list,

Our analysis pipeline is normally fed with proprietary raw file types from mass spectrometry instruments. These can currently only be read on windows systems where vendor DLLs are installed.

Since Cloudman/Galaxy does not interface with Windows nodes out of the box, I implemented a conversion tool wrapper that instantiates windows nodes on EC2 and lets them convert the raw files. It currently only does this, but there would of course be room for a number of other tools on the same windows image.

I know there are limitations such as Amazon's 20 node limit and the nodes not being controlled in Cloudman, but I wonder if my implementation would cause any serious problems with running this. Problems like security, etc (after all, the tool wrapper curls the user data to get the AWS access/secret keys. If anyone has comments on it, I'd love to hear them.

Current code for the windows image can be found on: https://bitbucket.org/glormph/galaxy-ec2-windows

And the tool that creates the windows node is on: https://bitbucket.org/glormph/adapt/changeset/ca13e548b85132049a918af84cfb06...

cheers, jorrit

-- Scientific programmer Mass spec analysis support @ BILS Janne Lehtiö / Lukas Käll labs SciLifeLab Stockholm

___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at:

http://lists.bx.psu.edu/