I’ve been trying to think of something less confusing, but have come up empty so far.
For me, MCE is confusing because I tried to think of why Moby needed a Community Edition. It’s wasn’t until scanning through this thread that I learned the definition. With the rebranding push of Docker to CE and EE, putting out an acronym with CE in it will get incorrectly associated.
While engine may be a name more known by the developers, this is also the main audience of GitHub repos, so I’m less concerned of confusion with that name.
Huh, I hadn’t even thought of the possible confusion by the “CE” in
"MCE". That’s a good point.
I’m not concerned about confusion between “Docker Engine” and “Moby
Engine”. However I remain worried about confusion between “Moby
Engine” and “Moby”. We need to be confident that the community can
CLEARLY understand the difference between 1) The Moby Project, and 2)
Moby Engine which is part of The Moby Project. Are we really confident
in that?
As long as we have the project itself create its own identity that is more than just the engine, I think this can work. If moby just remains the engine, then I think that may become a problem.
I’m going to introduce another name because I look at the Moby Project as “Docker’s Fedora” and the (possibly temporary) landing place for things Docker is releasing to the community. The other Moby to me is the “Moby OS”, aka the project based around the Moby Tool and Linuxkit components that we migrate out of Linuxkit. Feel free to wack me upside the head with a wet trout, or whatever the Docker tradition is, for adding new confusing terms.
With that term, I think we have at least 4 areas to minimize confusion (I’m using moby/engine as the placeholder for the new name because I can’t think of anything better):
Existing docker developers trying to find where everything moved.
moby/engine vs Moby Project
moby/engine vs docker/docker-ce
moby/engine vs Moby OS
For 1, I think they’ll figure it out eventually no matter what it’s called. I lean towards making the new name make sense to them because we’re talking about a developer facing repo name. Users are going to pull docker-ce from docker.com.
For 2, this needs time and successful projects in the moby/* namespace. Doesn’t matter what we call it, if the engine is the only successful repo, then we’ll have people abbreviate it.
For 3, the connection between the two is going to make it very difficult to separate. Perhaps if the moby/engine has it’s own builds or gets pulled into other projects, people will see the difference. But this is also one of those “doesn’t matter what we call it” scenarios.
I believe there’s a concern about 4, and I share that. I can’t think of a name for moby/engine that doesn’t still have the risk of confusion since it’s all under moby/. The best I can come up with is naming the other repos with a prefix that indicates they are part of the Moby OS explicitly. Perhaps moby/mobyos- (e.g. moby/mobyos-cli). Then there’s some verbal separation between talking about the Moby Project (moby/), Moby OS (moby/mobyos-), and a repo in the Moby Project (moby/engine).
I’m thinking simply container-engine for the binary name. It’s unsurprising from the repo name, it doesn’t have neither moby nor docker in it, just like any other project in the moby project. What do you think?
Related to this (even though not a responsibility for the Moby project); would there be a way to override this name? Thinking how this would be dealt with in the Docker CE build/packaging
For now, Docker can simply rename the container-engine binary to dockerd, and if usage output is a concern, we could use $0 there if it’s not already the case.
As far as the other binaries are concerned:
docker-containerd* -> containerd*
docker-runc -> runc
docker-init -> tini
docker-proxy -> $SOMETHING-proxy where $SOMETHING could be libnetwork, userland, nat, or anything you prefer.
These would keep their current name in docker releases.
The PROJECT name must clarify its relationship to Moby. Specifically it’s a sub-project of Moby, but distinct from Moby itself.
The PROJECT name must clarify its relationship to Docker. Specifically that it’s not Docker, and it’s not a feature or product if Docker.
The PROJECT name must clarify its function as a standardized starting point for a Moby assembly. 80% of Moby developers should probably start from this project instead of from scratch.
It should be assumed that the PROJECT is permanent. It may change in architecture over time, but its function as a standardized starting point for 80% of Moby developers will always be needed.
The PROJECT name should optimize for clarity and simplicity for the entire Docker community, not just for experienced contributors and maintainers.
If possible the PROJECT name should optimize for familiarity. For example well-known words are better than obscure ones. For well-known words, well-understood definitions are preferred to unusual ones
The REPOSITORY name must be consistent with the project name.
The REPOSITORY name must make sense standalone, without the full github URL. A good test for this is whether it causes unnecessary name collisions and confusion when cloned locally.
The BINARY names must share a common prefix, like docker binaries today.
The BINARY names must not require renaming in downstream distros. Specifically Docker CE should ship the binaries under the same names. This means there will be no “dockerd” in Docker CE.
The BINARY names should allow for individual binaries to appear or disappear from one version to the next. In other words binary names should be considered implementation details of the project.
The PROJECT VERSIONING should be distinct from Docker, both in schema and cadence.
I reserve the right to add criteria as I think lf them
Based on these criteria, I think the following suggestions DO NOT FIT THE CRITERIA:
“MCE”
“Engine”
“Container Engine”
“MobyOS”
Here is a new plan below. To move things forward I am pre-emptively declaring this plan “plan A”. Unless I am convinced by a counter-proposal this week, we will go with plan A next week.
@vieux please can you get the checklist ready so that we can execute the change ON MONDAY JULY 24. That is our deadline. We have delayed long enough, the community needs clarity.
Plan A is this:
project name: Moby Core
project short description: a modular base for the Moby Project
project longer description: Moby Core is a standard, modular base which Moby developers can adapt and extend to create custom container platforms with minimal effort. It aims to support 80% of use cases for Moby.
This means there will be no “dockerd” in Docker CE.
This seems like a problem. Today people run dockerd to start the daemon. If there is nothing called dockerd we will break a bunch of installations. Should Docker CE provide a symlink for backwards compatibility?
a modular base for the Moby Project
Extrapolating from this description it sounds like the future of this repo is to retain roughly the same scope of features, but the architecture will change to be more modular. Does that sound right?
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 Dockerfile and 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.
Could you please consider allowing use the trademark for compatibility reason?
For instances, Fedora/CentOS contains /etc/redhat-release, Linux supports AF_UNIX sockets, Iceweasel reports itself to be “Firefox”, Wine/ReactOS reports itself to be “Microsoft Windows”.(And now even Windows reports itself to be “GNU/Linux”.)
I understand you might concern that Moby maintainers may modify Dockerfile specification without approval from Docker, Inc. and may harm the trademark.
So WDYT about this plan:
Docker, Inc. declares definition of “Dockerfile specification v17.05”, and that the “Dockerfile specification” is solely maintained by Docker, Inc. employees but can be implemented by anyone without explicit approval from Docker, Inc.
3rd parties may fork “Dockerfile specification” and add new build instructions, but forked specs SHOULD NOT use “Dockerfile” as the file name. Forked specs may still support the “Dockerfile” file name for compatibility, but forked specs SHOULD NOT allow using their own instructions in Dockerfile-compatible mode.
moby-core-daemon implements “Dockerfile specification v17.05”. For a while, it means we just keep maintaining the current daemon code base. When BuildKit ( GitHub - moby/buildkit: concurrent, cache-efficient, and Dockerfile-agnostic builder toolkit ) gets matured, moby-core-daemon is expected to translate Dockerfile to BuildKit LLB, and send it to buildd (the BuildKit daemon). moby-core-daemon also exposes raw LLB endpoint.
Docker, Inc. may implement Dockerfile → LLB translater in docker/cli when BuildKit gets matured. When Docker. Inc. updates “Dockerfile specification”, Docker, Inc. may update docker/cli implementation as well, but neither Docker, Inc. nor Moby maintainers are responsible for updating the moby-core-daemon-side implementation.
Can the daemon listen on both docker.sock and moby-core-daemon.sock for compatibility?
Thanks Solomon on thinking through various aspects of this difficult transition.
In order to track and execute, shall we use Splitting Moby & Docker · GitHub and track all of the identified next steps ? Consolidating and listing the items here. I can open issues for each of the items tracked by milestones and deadlines in the above project directly.
We also need a place in the repo to clearly articulate these Principles prominently
)