Expanding Mesos Ecosystems: Enabling Mesos on Windows

### Overview In this talk, Microsoft engineers Jeff Coffler and Andrew (Andy) present their ongoing work porting the Apache Mesos agent to Windows and overhauling the Mesos build system using CMake. Rather than fundamentally redesigning Mesos, the project introduces a native Windows Mesos agent, enabling hybrid Mesos and DC/OS clusters that schedule both Windows and Linux workloads side-by-side using standard constraints like operating system type. The presentation highlights container isolation approaches on Windows, a ground-up refactoring of CMake build configurations, continuous integration improvements, and customer validation.

### Key Topics - **Native Windows Agent Support:** Bringing Mesos agent capabilities to Windows without changing the core cluster or requiring changes to existing Linux Mesos masters. - **Process Isolation & Containers:** Leveraging Windows Job Objects for raw process resource limiting alongside native Windows Docker container isolation. - **CMake Modernization:** Transitioning Mesos away from GNU Autotools toward modern, target-based CMake build files to support multi-platform generation (Visual Studio MSBuild, Makefiles, Ninja) and substantially reduce build times. - **Testing and CI Infrastructure:** Introducing Windows review bots and CI integration to prevent build regressions and steadily increase test coverage. - **Hybrid Deployments & Production Status:** Demonstrating side-by-side scheduling of services (such as Microsoft IIS on Windows and nginx on Linux) and presenting on-premises production adoption by Ctrip International.

### Technical Details - **Containerizers on Windows:** Because Linux cgroups and Linux-style namespaces do not exist on Windows, the Mesos containerizer uses Windows Job Objects to apply hard limits on CPU and RAM for raw processes. For container workloads, Mesos delegates directly to the native Windows Docker daemon, honoring resource isolation limits. - **CMake Dependency Refactor:** The initial Windows port copied Autotools directory inclusions into CMake. Andy refactored the build system to use proper modern CMake target graphs (e.g., target-based dependencies with `target_link_libraries` and `add_library ... INTERFACE` for the Stout header-only library). This refactor eliminated over 1,000 lines of boilerplate configuration while adding only ~200 lines, cleanly propagating transitive dependencies across third-party libraries (e.g., glog, zookeeper). - **Build Speed Optimizations:** Windows build times were reduced from nearly an hour down to roughly 18 minutes by fixing dependency graphs and generating precompiled headers via the `Cotire` CMake module. - **Long Paths & Bindings:** NTFS long paths are supported natively without requiring manual Windows registry edits. Java bindings were brought to the CMake master branch to enable marathon orchestration, while Python bindings remain pending. - **CI and Testing:** A dedicated Windows review bot runs on incoming patches, dramatically reducing master branch breakages from several times a week to approximately once a month. The Windows test suite covers 630 Mesos tests, focusing on ported modules (such as Libprocess and the fetcher).

### Takeaways - Mesos clusters can seamlessly integrate Windows agents to manage mixed Windows/Linux workloads without altering cluster master nodes. - Modernizing the build system with target-based CMake provides faster, cleaner cross-platform builds across Windows and Linux, setting the stage to default to CMake over Autotools in the Mesos ecosystem. - While basic process and Docker containment, hybrid DC/OS deployment, and production use (e.g., Ctrip) are established, ongoing priorities include adding unit tests, porting the fetcher, finishing authentication plugins (e.g., CRAM-MD5), and investigating master porting requirements such as LevelDB.