In that case, is it possible to make a stripped down Slave implementation that only does the minimum to interact with the Master to relay the resources and tasks?
I'm not sure I understand fully the complete responsibilities of the Slave and how the Master sees it. On Fri, Feb 20, 2015 at 3:49 PM, Timothy Chen <[email protected]> wrote: > Hi Alexandre, > > That seems reasonable, for Mesos requirement standpoint a slave minimal > needs to be able to recieve and send HTTP messages to executor. > > There are other wants from a containerizer standpoint such as logging, > isolation, updating limits, etc. But not everything is a hard requirement. > > Tim > > On Feb 20, 2015, at 12:30 PM, Alexandre Mclean <[email protected]> > wrote: > > 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 <[email protected]> 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 < >> [email protected]> 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 < >>> [email protected]> 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 < >>>> [email protected]> 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 > > -- Alexandre
