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
