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 <alexandre.mcl...@gmail.com> > 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 <t...@mesosphere.io> 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.mcl...@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 <james.defel...@gmail.com> >>>> 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.mcl...@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
