Hi Kyle,

We have a similar ongoing development wherein we are working on integrating
our Swift framework ( swift-lang.org ) with Galaxy. The goal is to enable
Galaxy based applications to run on a variety of distributed resources via
various integration schemes as suitable to application and underlying
execution environment.

Here is an abstract of a paper (co-authored with Ravi, who responded on
this thread) we will be presenting in a workshop at the upcoming SC 13
conference:

"The Galaxy platform is a web-based science portal for scientific computing
supporting Life Sciences users community. While user-friendly and intuitive
for doing small to medium scale computations, it currently has a limited
support for large-scale, parallel and distributed computing. The Swift
parallel scripting framework is capable of composing ordinary applications
into parallel scripts that can be run on multi-scale distributed and
performance computing platforms. In complex distributed environments, often
the user end of application lifecycle slows down because of the technical
complexities brought in by the scale, access methods and resource
management nuances. Galaxy offers a simple way of designing, composing,
executing, reusing, and reproducing application runs. An integration
between Swift and Galaxy systems can accelerate science as well as bring
the respective user communities together in an interactive, user-friendly,
parallel and distributed data analysis environment enabled on a broad range
of computational infrastructures."

Kindly let us know if you need a hands on for the various tools we have
already developed.


Best,
Ketan



On Mon, Oct 28, 2013 at 3:07 PM, Kyle Ellrott <kellr...@soe.ucsc.edu> wrote:

> I don't think implementation will be very difficult. The bigger question
> is this a technology people are open to?
> The nearest competitor is YARN (
> http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/YARN.html).
> Mesos seems a bit more geared toward general purpose usage (with several
> existing frameworks), while YARN seems more specific to Hadoop. But I'd be
> glad to hear some other thoughts.
>
> Kyle
>
>
> On Mon, Oct 28, 2013 at 12:55 PM, Ravi K Madduri <madd...@mcs.anl.gov>wrote:
>
>> Kyle
>> This is something I am very interested in. The three parts below make
>> sense to me. I would be very happy to discuss further and provide any help
>> to move this forward.
>>
>> Regards
>> On Oct 26, 2013, at 2:43 PM, Kyle Ellrott <kellr...@soe.ucsc.edu> wrote:
>>
>> I think one of the aspects where Galaxy is a bit soft is the ability to
>> do distributed tasks. The current system of split/replicate/merge tasks
>> based on file type is a bit limited and hard for tool developers to expand
>> upon. Distributed computing is a non-trival thing to implement and I think
>> it would be a better use of our time to use an already existing framework.
>> And it would also mean one less API for tool writers to have to develop for.
>> I was wondering if anybody has looked at Mesos ( http://mesos.apache.org/). 
>> You can see an overview of the Mesos architecture at
>> https://github.com/apache/mesos/blob/master/docs/Mesos-Architecture.md
>> The important thing about Mesos is that it provides an API for C/C++,
>> Java/Scala and Python to write distributed frameworks. There are already
>> implementations of frameworks for common parallel programming systems such
>> as:
>>  - Hadoop (https://github.com/mesos/hadoop)
>>  - MPI (
>> https://github.com/apache/mesos/blob/master/docs/Running-torque-or-mpi-on-mesos.md
>> )
>>  - Spark (http://spark-project.org)
>> And you can find example Python framework at
>> https://github.com/apache/mesos/tree/master/src/examples/python
>>
>> Integration with Galaxy would have three parts:
>> 1) Add a system config variable to Galaxy called 'MESOS_URL' that is then
>> passed to tool wrappers and allows them to contact the local mesos
>> infrastructure (assuming the system has been configured) or pass a null if
>> the system isn't available.
>> 2) Write a tool runner that works as a mesos framework to executes single
>> cpu jobs on the distributed system.
>> 3) For instances where mesos is not available at a system wide level (say
>> they only have access to an SGE based cluster), but the user wants to run
>> distributed jobs, write a wrapper that can create a mesos cluster using the
>> existing queueing system. For example, right now I run a Mesos system under
>> the SGE queue system.
>>
>> I'm curious to see what other people think.
>>
>> Kyle
>> ___________________________________________________________
>> 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/
>>
>> To search Galaxy mailing lists use the unified search at:
>>  http://galaxyproject.org/search/mailinglists/
>>
>>
>>  --
>> Ravi K Madduri
>> MCS, Argonne National Laboratory
>> Computation Institute, University of Chicago
>>
>>
>
> ___________________________________________________________
> 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/
>
> To search Galaxy mailing lists use the unified search at:
>   http://galaxyproject.org/search/mailinglists/
>



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

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

Reply via email to