Moby Core aims to remove all dependencies on Docker products and Docker trademark. This is important for criteria 1: clarify the relationship to Docker. That includes removing terms like
docker-compose.yml from the Moby Core API and its specification.
This would have to be done gradually, and in a way that provides continuity for current API users. It would probably involve deprecating the current
/build API endpoint (which badly needs an overhaul anyway) and either replacing it with something more flexible, or taking it out of scope entirely and leave it to the higher layers to implement build. This is the path that Kubernetes has chosen for example. There are several active projects implementing higher-level container build primitives decoupled from the underlying execution engine.
To be clear we should work on this in parallel to the project renaming. Consider this call for volunteers to propose a transition plan for Moby Core build features.
Similar to the Dockerfile topic: Moby Core should plan to get rid of
/var/run/docker.sock to clarify thast Moby Core is not Docker.
Of course this should be done gradually, and managed carefully to provide continuity to users.
Consider this a call for volunteers to propose a
docker.sock transition plan.
I think that would be confusing, because it will give the impression that we are breaking the API, when in fact we are only renaming the API but preserving backwards compatibility.
However, when we implement our Dockerfile transition plan or docker.sock transition plan, that transition might require changes to the Moby Core API. If those are breaking changes (for example deprecating the
/build endpoint) then that would justify a major version bump.
Basically, we should stick to semver, and optimize for least surprise for API users.
I don’t have a strong opinion, as long as we allow the binary names to change easily from one version to the next.
I think it’s strictly a packaging issue. Upstream developers should avoid doing anything clever, and just assume that packagers are capable of handling a binary renames between versions - a pretty common packaging scenario. Maybe packagers will choose to create a symlink, or maybe they won’t. But we should let them deal with it.
My personal recommendation to packagers: don’t provide a symlink. It only kicks the can down the road since there will soon no longer be a single master daemon anyway. Any system installation that breaks when a daemon binary is renamed is way too brittle and should be fixed at the packaging or sysadmin level.
On the topic of modularity: yes, the architecture will change to be more modular, that is an explicit goal.
On the topic of scope: let’s not define a fixed scope of features for Moby Core right now. Instead, let’s define principles that maintainers can apply whenever they need to decide on scope. That way we can protect the project from bloat without crippling it.
I propose the following principles for determining whether a feature is in scope:
Principle 1: PURPOSE. Maintainers should only add features that contribute to the purpose of Moby Core, which is to help Moby developers create custom container platforms with minimal effort.
Principle 2: 80%. Moby Core aims to support 80% of the use cases for Moby. Therefore, it a feature helps at least 80% of Moby developers create custom container platforms with minimal effort, then it should be included, even if it doesn’t help the other 20%.
Principle 3: MODULARITY. Moby Core takes the form of a modular base to be extended adapted and extended. Therefore, all other things being equal, maintainers should err on the side of modularity.
For example, if maintainers cannot decide between A) a full implementation of a feature, or B) extension points which allow third-party modules to implement the feature; then they should default to option B.
Principle 4: INDEPENDENCE. Moby Core is independent of its downstream products. Therefore, maintainers should ignore downstream product priorities when deciding on feature scope.
For example, this clarifies that the Docker product roadmap does not influence the scope of Moby Core. This is important because the issue of influence by the Docker product roadmap (whether real or perceived) has often poisoned discussions of scope in the past.