Return-Path: X-Original-To: apmail-airavata-dev-archive@www.apache.org Delivered-To: apmail-airavata-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B85CF19931 for ; Wed, 27 Apr 2016 19:28:28 +0000 (UTC) Received: (qmail 92008 invoked by uid 500); 27 Apr 2016 19:28:28 -0000 Delivered-To: apmail-airavata-dev-archive@airavata.apache.org Received: (qmail 91962 invoked by uid 500); 27 Apr 2016 19:28:28 -0000 Mailing-List: contact dev-help@airavata.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@airavata.apache.org Delivered-To: mailing list dev@airavata.apache.org Received: (qmail 91952 invoked by uid 99); 27 Apr 2016 19:28:28 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 27 Apr 2016 19:28:28 +0000 Received: from airavatham.lan (c-68-45-73-203.hsd1.in.comcast.net [68.45.73.203]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 21C8A1A0110 for ; Wed, 27 Apr 2016 19:28:28 +0000 (UTC) From: Suresh Marru Content-Type: multipart/alternative; boundary="Apple-Mail=_6A5ABDC8-C835-4098-9306-4C123098E26B" Message-Id: <11AFDDA6-42F8-4AAB-9F7C-57CC460590A0@apache.org> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Design of Mesos/Aurora integration with Airavata on Jetstream Date: Wed, 27 Apr 2016 15:28:26 -0400 References: <9D29711D-DA19-45C2-BEFE-CA5D673E94FE@iu.edu> <5720F535.5050204@biochem.uthscsa.edu> <4630BFBA-78F1-425D-B355-BF57CAA782D1@apache.org> To: Airavata Dev In-Reply-To: X-Mailer: Apple Mail (2.3124) --Apple-Mail=_6A5ABDC8-C835-4098-9306-4C123098E26B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 27, 2016, at 2:57 PM, Gourav Rattihalli = wrote: >=20 >=20 > Hi Suresh, >=20 > First of all I would like to commend you for starting this discussion. = This is exactly kind of the mailing list engagement we would like to see = as part of your GSOC. You already drew Emre=E2=80=99s attention, often = discussions done in isolation undermine this impact. So good job on a = start and we will expect over the summer you will engage lot more. >=20 >=20 > Thanks. Yes, I plan to actively use this mailing list to keep my = design focused on real use cases, and also to get regular feedback. > =20 > Application dependency libraries, compiler versions can quickly get = tangled. You can choose to deploy Lmod (https://github.com/TACC/Lmod = ) within a VM to alleviate this but that = will be an over kill. Eventually containers will hopefully alleviate = this problem. >=20 >> The worker VMs need to have the Mesos libraries installed and the = Mesos master needs to be configured with the IPs of the worker VMs. So, = if new VMs are created each time, we will develop the playbook for the = creation of the Mesos cluster on the fly, and then launch the = application on it. >=20 >=20 > Can the slave not register itself dynamically and report its IP = Address? With either multiple applications per VM or one per VM, you = will need to look into the capability of a persistent master and short = lived elastic slave instances right? May be I am mis-understating your = questions. Can you help clarify this more?=20 >=20 >=20 > Yes, this is possible, and was the first of the two options I had = emailed. Can you elaborate on the second option, may be I missed what you tried = to convey? Lets put aside how many applications per vm for this = discussion since thats orthogonal.=20 > To support this kind of elasticity, we will work on developing a = script/playbook to install the Mesos libraries on the new slaves/agents = and connect them with the master. Can you please develop them in Airavata repo itself? I mean lets not = make perfection be the enemy here and start sending pull requests as you = bake these playbooks. You can put the scripts here - = https://github.com/apache/airavata/tree/develop/modules/cloud/ansible-play= books = (note that it is develop branch).=20 You can read about contributions here - = http://airavata.staging.apache.org/community/how-to-contribute-code.html = = (we need to move these instructions to the new website). Suresh >=20 > Thanks, > Gourav >=20 >> On Apr 27, 2016, at 1:21 PM, Emre Brookes > wrote: >>=20 >> Pierce, Marlon wrote: >>> Thanks, Gourav, this is great. How will the design differ in the two = cases? >>>=20 >>> Since installing the applications is not a simple task and there = aren=E2=80=99t good docker libraries (for example) for many of them, I = would assume that we would have a collection of VMs that have the codes = already installed. >> FWIW, that model would work well with GenApp usage also. Although, I = can imagine a scenario where a part of job initialization script = (running under the already "code installed" VM) checks for updates to = the code and installs them, but that can be independent of = Airavata/Aurora/Mesos's knowledge. >>=20 >> -Emre >>=20 >>>=20 >>> Marlon >>>=20 >>>=20 >>> From: Gourav Rattihalli >> >>> Reply-To: "dev@airavata.apache.org = >" = = >> >>> Date: Wednesday, April 27, 2016 at 1:01 PM >>> To: "dev@airavata.apache.org = >" = = >> >>> Subject: Design of Mesos/Aurora integration with Airavata on = Jetstream >>>=20 >>> Hi Dev's, >>>=20 >>> I have been working on the integration of Apache Aurora and Mesos = with Airavata and Jetstream. Using Mangirish's latest code, VMs can now = be created using on Jetstream. I want to understand how Airavata is = likely to use the VMs for applications. Will airavata re-use existing = VMs for successive applications for a given community, or will new VMs = be created for each application? This will decide how we design the = automated creation of a Mesos cluster using the new VMs that are = created. I understand that we will have a Mesos master VM that will run = all the time on Jetstream. >>>=20 >>> Here is the Job submission flow that I am assuming: >>>=20 >>> Airavata Client--> Airavata = Server-->(Orchestrator-->GFAC)-->My-Apache-Aurora-module-->(A script = will create .aurora configuration file that will be used to launch the = job)-->Aurora/Mesos-->VMs >>>=20 >>> So, I will design a module that will work with Orchestrator-->GFAC = to generate the appropriate Apache Aurora script to be submitted to the = Aurora master. >>>=20 >>> Please let me know if there are any comments, suggestions on this = plan. >>>=20 >>> --=20 >>> Regards, >>> Gourav Rattihalli >>=20 >=20 >=20 >=20 >=20 > --=20 > Regards, > Gourav Rattihalli --Apple-Mail=_6A5ABDC8-C835-4098-9306-4C123098E26B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Apr 27, 2016, at 2:57 PM, Gourav Rattihalli <grattih1@binghamton.edu> wrote:


Hi = Suresh,

First of all = I would like to commend you for starting this discussion. This is = exactly kind of the mailing list engagement we would like to see as part = of your GSOC. You already drew Emre=E2=80=99s attention, often = discussions done in isolation undermine this impact. So good job on a = start and we will expect over the summer you will engage lot = more.


Thanks. Yes, I plan to = actively use this mailing list to keep my design focused on real use = cases, and also to get regular feedback.
 
Application dependency libraries, compiler versions can = quickly get tangled. You can choose to deploy Lmod (https://github.com/TACC/Lmod) within a VM to alleviate = this but that will be an over kill. Eventually containers will hopefully = alleviate this problem.

The worker VMs need to have the Mesos libraries = installed and the Mesos master needs to be configured with the IPs = of the worker VMs. So, if new VMs are created each time, we will develop = the playbook for the creation of the Mesos cluster on the fly, and then = launch the application on it.

Can the slave not = register itself dynamically and report its IP Address? With either = multiple applications per VM or one per VM, you will need to look into = the capability of a persistent master and short lived elastic slave = instances right? May be I am mis-understating your questions. Can you = help clarify this more? 


Yes, this is possible, and was the = first of the two options I had emailed. =

Can you elaborate on the second option, may be I = missed what you tried to convey? Lets put aside how many applications = per vm for this discussion since thats orthogonal. 

To = support this kind of elasticity, we will work on developing a = script/playbook to install the Mesos libraries on the new slaves/agents = and connect them with the master.

Can you please develop them in Airavata repo = itself? I mean lets not make perfection be the enemy here and start = sending pull requests as you bake these playbooks. You can put the = scripts here - https://github.com/apache/airavata/tree/develop/modules/cloud/a= nsible-playbooks (note that it is develop = branch). 

You can read about = contributions here -  http://airavata.staging.apache.org/community/how-to-contribute-= code.html (we need to move these instructions to the new = website).

Suresh


Thanks,
Gourav

On Apr = 27, 2016, at 1:21 PM, Emre Brookes <emre@biochem.uthscsa.edu> wrote:

Pierce, Marlon wrote:
Thanks, Gourav, this is = great. How will the design differ in the two cases?

Since installing the applications is not a simple task and = there aren=E2=80=99t good docker libraries (for example) for many of = them, I would assume that we would have a collection of VMs that have = the codes already installed.
FWIW, that model = would work well with GenApp usage also.  Although, I can imagine a = scenario where a part of job initialization script (running under the = already "code installed" VM) checks for updates to the code and installs = them, but that can be independent of Airavata/Aurora/Mesos's = knowledge.

-Emre


Marlon


From: Gourav Rattihalli <grattih1@binghamton.edu <mailto:grattih1@binghamton.edu>>
Reply-To: "dev@airavata.apache.org <mailto:dev@airavata.apache.org>" <dev@airavata.apache.org <mailto:dev@airavata.apache.org>>
Date: = Wednesday, April 27, 2016 at 1:01 PM
To: "dev@airavata.apache.org <mailto:dev@airavata.apache.org>" <dev@airavata.apache.org <mailto:dev@airavata.apache.org>>
Subject: Design of Mesos/Aurora integration with Airavata on = Jetstream

Hi Dev's,

I have been working on the integration of Apache Aurora and = Mesos with Airavata and Jetstream. Using Mangirish's latest code, VMs = can now be created using on Jetstream. I want to understand how Airavata = is likely to use the VMs for applications. Will airavata re-use existing = VMs for successive applications for a given community, or will new VMs = be created for each application? This will decide how we design the = automated creation of a Mesos cluster using the new VMs that are = created. I understand that we will have a Mesos master VM that will run = all the time on Jetstream.

Here is the Job = submission flow that I am assuming:

Airavata = Client--> Airavata = Server-->(Orchestrator-->GFAC)-->My-Apache-Aurora-module-->(A = script will create .aurora configuration file that will be used to = launch the job)-->Aurora/Mesos-->VMs

So, I will design a module that will work with = Orchestrator-->GFAC to generate the appropriate Apache Aurora script = to be submitted to the Aurora master.

Please = let me know if there are any comments, suggestions on this plan.

-- 
Regards,
Gourav Rattihalli





-- 
Regards,
Gourav = Rattihalli

= --Apple-Mail=_6A5ABDC8-C835-4098-9306-4C123098E26B--