Return-Path: X-Original-To: apmail-mesos-user-archive@www.apache.org Delivered-To: apmail-mesos-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id AD11717FCF for ; Fri, 20 Feb 2015 20:32:55 +0000 (UTC) Received: (qmail 61442 invoked by uid 500); 20 Feb 2015 20:32:55 -0000 Delivered-To: apmail-mesos-user-archive@mesos.apache.org Received: (qmail 61398 invoked by uid 500); 20 Feb 2015 20:32:55 -0000 Mailing-List: contact user-help@mesos.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@mesos.apache.org Delivered-To: mailing list user@mesos.apache.org Received: (qmail 61388 invoked by uid 99); 20 Feb 2015 20:32:55 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Feb 2015 20:32:55 +0000 X-ASF-Spam-Status: No, hits=2.5 required=5.0 tests=FREEMAIL_REPLY,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of alexandre.mclean@gmail.com designates 209.85.214.177 as permitted sender) Received: from [209.85.214.177] (HELO mail-ob0-f177.google.com) (209.85.214.177) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Feb 2015 20:32:51 +0000 Received: by mail-ob0-f177.google.com with SMTP id wp18so25327074obc.8 for ; Fri, 20 Feb 2015 12:30:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=3tLFDokWdvhf9AoDDPbJ2/hB3SOe4jNdyeYjhxY8e8k=; b=JnUtSwb0CfnFUhU2FB0BpzGXD9zH6ddU/YyI1zSfta3y0rphX9SpjsEKk7wQfeeuhf EW8u4EHYIc2Fi2iAFEoKpsYPIhSDNJg9v5V/WBFjSnnj0GTyksTd+ZM5imYaD9LG6JDe R0WIo5FX8Fzj7ULMIBVniHWIz/VsJXM0QCQ4JIYDEjD6IkrS21ztUEdAMzkB0ZiP7RBD N1ytmfF5PkdVLCkjMlXLX1UwGim0QfFsuiI1Hdfn9tyDM0owEiMtNXTLRtS7WQYGZpRD 4n8P/K5SjQqMi12ICx2vVitKJWApanJXrRsj4b6BWXuIpRECJcspWVWaLfLCf2fsfC1R nOGQ== MIME-Version: 1.0 X-Received: by 10.202.57.195 with SMTP id g186mr7457270oia.86.1424464215569; Fri, 20 Feb 2015 12:30:15 -0800 (PST) Received: by 10.202.170.7 with HTTP; Fri, 20 Feb 2015 12:30:15 -0800 (PST) In-Reply-To: References: Date: Fri, 20 Feb 2015 15:30:15 -0500 Message-ID: Subject: Re: Compiling Slave on Windows From: Alexandre Mclean To: user@mesos.apache.org Content-Type: multipart/alternative; boundary=001a113cfe5c907ba0050f8aebb3 X-Virus-Checked: Checked by ClamAV on apache.org --001a113cfe5c907ba0050f8aebb3 Content-Type: text/plain; charset=UTF-8 Hi Tim, if we're operating in a cloud base environment (OpenStack), would that mean we could run this containerizer on the hypervisor host, or anywhere else, and manage remotely the executors inside Windows cloud instances? On Fri, Feb 20, 2015 at 3:14 PM, Tim Chen wrote: > Hi Alexandre, > > Porting the slave will not be straightforward since it inherently was > operating with the assumption of a unix based system throughout. > > What is much easier to accomplish, is to provide a containerizer in Mesos > that can manage VMs, which can then spawn Windows based VMs. This does has > higher perf hit than containers ofcourse. > > Tim > > On Fri, Feb 20, 2015 at 11:43 AM, Alexandre Mclean < > alexandre.mclean@gmail.com> wrote: > >> Hi James, >> I agree this is a compelling feature, but it might not be an absolute >> requirement for many use cases. >> >> We're evaluating Mesos to build custom frameworks for distributed >> computation that needs to be cross-platform (Windows mainly), where some >> tasks would be oriented for video rendering (e.g render farm, like many >> existing commercial solutions). This is pretty popular in the Entertainment >> industry, like video games. >> >> We'd be willing to sacrifice that isolation and just be able to build a >> job distribution framework on top of Mesos. >> >> Also, correct me if I'm wrong but Slaves can already run on OSX which has >> no support for cgroups. >> >> I'm curious to know if anyone tried this before and what are the blocking >> issues to port the Slave component. >> >> Otherwise, maybe someone can propose an alternative approach to >> accomplish this. >> >> Many thanks >> >> >> >> >> >> On Fri, Feb 20, 2015 at 2:26 PM, James DeFelice > > wrote: >> >>> One of the major, compelling cases for using mesos is the resource >>> partitioning and isolation between process groups that slave containerizers >>> manage. And that, of course, OS containers are lightweight and low-overhead. >>> >>> Windows has a ways to go here. You can read about Drawbridge, or even >>> the latest speculation re: Docker+Windows Server integration and what that >>> might look like. >>> >>> On Fri, Feb 20, 2015 at 12:17 AM, Alexandre Mclean < >>> alexandre.mclean@gmail.com> wrote: >>> >>>> Hi everyone, >>>> what are the current limitations to make the Slave work on a Windows >>>> platform? >>>> >>>> Would it be possible to extract the slave component from the main Mesos >>>> codebase and compile it on Windows? >>>> >>>> Also, could we have a pure implementation of the Slave that wouldn't >>>> depend on libmesos, like we do for the newest bindings like mesos-go? Does >>>> it even make sense to want this? >>>> >>>> -- >>>> Alexandre >>>> >>> >>> >>> >>> -- >>> James DeFelice >>> 585.241.9488 (voice) >>> 650.649.6071 (fax) >>> >> >> >> >> -- >> Alexandre >> > > -- Alexandre --001a113cfe5c907ba0050f8aebb3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Tim,
if we're operating in a cloud base environ= ment (OpenStack), would that mean we could run this containerizer on the hy= pervisor host, or anywhere else, and manage remotely the executors inside W= indows cloud instances?

On Fri, Feb 20, 2015 at 3:14 PM, Tim Chen <tim@mesospher= e.io> wrote:
Hi Alexandre,

Porting the slave will not be straightf= orward since it inherently was operating with the assumption of a unix base= d system throughout.=C2=A0

What is much easier to = accomplish, is to provide a containerizer in Mesos that can manage VMs, whi= ch can then spawn Windows based VMs. This does has higher perf hit than con= tainers ofcourse.
=
Tim

On Fri, = Feb 20, 2015 at 11:43 AM, Alexandre Mclean <alexandre.mclean@gmai= l.com> wrote:
Hi James,
I agree this is a compelling feature, but it might not be= an absolute requirement for many use cases.

We= 9;re evaluating Mesos to build custom frameworks for distributed computatio= n that needs to be cross-platform (Windows mainly), where some tasks would = be oriented for video rendering (e.g render farm, like many existing commer= cial solutions). This is pretty popular in the Entertainment industry, like= video games.

We'd be willing to sacrifice tha= t isolation and just be able to build a job distribution framework on top o= f Mesos.

Also, correct me if I'm wrong but= Slaves can already run on OSX which has no support for cgroups.=C2=A0

I'm curious to know if anyone tried this before an= d what are the blocking issues to port the Slave component.

<= /div>
Otherwise, maybe someone can propose an alternative approach to a= ccomplish this.

Many thanks





On Fri, Feb 20, 2015 at 2:26 PM, = James DeFelice <james.defelice@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
One of the major, compelling= cases for using mesos is the resource partitioning and isolation between p= rocess groups that slave containerizers manage. And that, of course, OS con= tainers are lightweight and low-overhead.

Windows has a = ways to go here. You can read about Drawbridge, or even the latest speculat= ion re: Docker+Windows Server integration and what that might look like.

On Fri, Feb 20, 2015 at 12:17 AM, Alexandre Mclean <= alexandre.m= clean@gmail.com> wrote:
Hi everyone,
what are the current limitations to make the= Slave work on a Windows platform?

Would it be pos= sible to extract the slave component from the main Mesos codebase and compi= le it on Windows?

Also, could we have a pure imple= mentation of the Slave that wouldn't depend on libmesos, like we do for= the newest bindings like mesos-go? Does it even make sense to want this?

--
Alexandre=



<= font color=3D"#888888">--
James DeFelice
585.241.9488 (voice)650.= 649.6071 (fax)



<= font color=3D"#888888">--
Alexandre




--
=
Alexandre
--001a113cfe5c907ba0050f8aebb3--