Skip to content
This repository has been archived by the owner on Dec 10, 2019. It is now read-only.

Latest commit

 

History

History
47 lines (31 loc) · 3.15 KB

2014-11-11--00-00.md

File metadata and controls

47 lines (31 loc) · 3.15 KB
Raw

Docker Tuesday #2 -- Proposal Review

11 November 2014; 10:05 AM - 12:00 PM.

Maintainers: Michael Crosby, Jessie Frazelle, Solomon Hykes, Arnaud Porterie, Cristian Staretu, Tibor Vass

##Topic: Review of Clustering Proposal #8859

Reference: Getting Started with Docker Cluster

Presenters: Andrea Luzzardi, Victor Vieux

  • Full IRC transcript is available here.
  • YouTube video of session is available here.

###Key Takeaways for Clustering

We articulated two guiding principles for Docker Clustering:

  1. "Batteries are Included": Have a default config that works out-of-box. For an excellent developer experience, we want a "batteries included" approach that enables users to benefit from clustering with zero-effort, without having to leave the native Docker experience to set something else up. This means that Docker Clustering will ship with default configurations for service discovery, shared state, and scheduling. Suggested implementation paths were two-fold: via 1) zero_conf or 2) the Docker Hub.

  2. Plug-in Architecture: You Can Swap Out the Defaults, including Clustering itself. A plug-in architecture is essential to Docker. Users should be able to bootstrap with default configurations provided for Docker Clustering, but then be able to select the solution of their choice. Having the plug-in architecture defined upfront is critical to the project.

###Discussion Implementing a "batteries included" approach is relatively straightforward once the default configurations are decided, but defining the plugin architecture is challenging.

After some discussion, we concluded that Andrea/Victor should attempt a "poor man's plug-in" to Docker, using Clustering: this excercise will expose what is needed from the Docker Core. Also, if the interface was written down, others could hack on it.

Start with, for example, the idea clustering is a plugin. What do you need from the Docker Core? Immediate thoughts:

  • The ability to register a new command
  • The ability to highjack the api to replace anything (for example, docker ps)

We discussed considering plug-ins to be at the job level; think about piggy-backing on the remote api and relying on jobs. We talked about bringing libchan into the picture, for a jobs v2. We talked about the fact that Clustering, itself, was separate from the docker binary, and the notion that "we will only merge it as a plug-in".

But these were just first thoughts. Now to the steps forward:

###Action Items Andrea/Victor

  • Update #8859 to define the proposed default out-of-the-box configurations that will be implemented for Docker Clustering.
  • Ship an example Clustering Binary that's not a plug-in; understand the entry points that are needed from Docker.
  • Submit a proposal on how to split out Clustering as a plug-in.

Meta After plug-in Proposal is submitted by Andrea/Victor:

  • Create PR(s) that implement the Proposal for the Clustering Plug-in Architecture.