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.boe...@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/ca13e548b85132049a918af84cfb063e62615bcb
>
> 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/

___________________________________________________________
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/

Reply via email to