New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Find a good an non-confusing home for the remaining monolith #32871

Open
vieux opened this Issue Apr 27, 2017 · 31 comments

Comments

@vieux
Copy link
Collaborator

vieux commented Apr 27, 2017

This repo is the home of the moby tool (see #32859)
Today we have the code of the legacy "docker engine" (a monolith to be split out in multiple components) at the root and it's very confusing.

To help with the split we should probably move the "docker engine" code somewhere else.
Yes it will break all the open PRs, but I believe it's a change we have to make.

How about a folder ?

@vieux vieux added the area/project label Apr 27, 2017

@vieux vieux added this to the splitting_moby_and_docker milestone Apr 27, 2017

@vieux vieux referenced this issue Apr 27, 2017

Open

[META] Splitting moby and docker #32867

4 of 14 tasks complete
@AkihiroSuda

This comment has been minimized.

Copy link
Member

AkihiroSuda commented Apr 27, 2017

How about a folder ?

Do you mean creating a folder in this repository?
Can we use git branch instead?

@vdemeester

This comment has been minimized.

Copy link
Member

vdemeester commented Apr 27, 2017

@AkihiroSuda using branches will be really confusing. I think moving the docker/docker source in a engine folder might make sence but it means we need to have a safe url before (see #32862) because it's going to break all go imports (which didn't for the move because of redirection).

@estesp

This comment has been minimized.

Copy link
Contributor

estesp commented Apr 27, 2017

Seems there is another step here that we talked about in the F2F last Thursday--to help clarify that "Docker CE" is still open source, and at some point moby/moby will not be the home for that. We talked about a place to at least say "This is where you will build Docker CE" in the future, and for now it may be a simple clone in of the remaining monolith and make binaries?

@vieux

This comment has been minimized.

Copy link
Collaborator

vieux commented Apr 27, 2017

I agree with @vdemeester using a branch will be really confusing.

See see only two potentials solutions:

  1. Using a folder like engine inside moby/moby, as @vdemeester pointed out, we needs a custom url for imports first. This might still be confusing since we will still have a mix of "engine" and "moby" issues in the same repo until engine disappears because it's fully componentized.

  2. Using a separate repo, such as, for example moby/monolith. This would leave the moby/moby repo with simply the moby tool and the assemblies -> seems to match the scope of project. We have two ways to achieve this

    a. create a brand new moby/monolith repo, move the code there and close all "engine" PRs today in moby/moby (probably recreate the most recents on moby/monolith). This would imply a full cleanup of issues and PRs...

    b. move moby/moby to moby/monolith and create a brand moby/moby with the project readme + moby tool + assemblies inside. Depending on how github.com handles redirections, it might break go imports. Also the moby/moby will look pretty empty at first...

So no perfect solution.

Am I missing an option ?
What's your preference ? 1 2.a or 2.b ?

@mlaventure I believe you have an opinion ? @shykes I'm sure you do :D

@ehazlett

This comment has been minimized.

Copy link
Contributor

ehazlett commented Apr 28, 2017

Depending on the redirects, I think 2.b would be the best. It would at least send people to the repo that is the current monolith and give us a clean slate to progress with the proper project scope for the tool and assemblies. We will probably want to look into custom URLs for the imports as all of these will probably break the imports.

As @estesp said, I think it would be nice to have a place where Docker CE resides. I know it's not desired to have the monolith be something like docker/docker-ce but I also think it's important to get that sooner rather than later to show our intent and help clarify the future. How crazy is it to have docker/docker-ce (or similar) be the monolith and pull components out into the moby org? This would eventually be reduced to nothing but the "blueprint" that is used to build but would be the long term home with a single move.

@duglin

This comment has been minimized.

Copy link
Contributor

duglin commented Apr 28, 2017

  • moby/moby - new repo for the moby tool
  • moby/ce - today's moby/moby which will slowly shrink as we pull out stuff. This is where people would build the engine from today
  • moby/??? - future repos for each component we pull out
@shykes

This comment has been minimized.

Copy link
Collaborator

shykes commented Apr 28, 2017

@duglin the engine/monolith and Docker CE are 2 different things. It seems inevitable that we choose a name for the monolith - but I think it's important that that name not be "docker" or "ce".

Also:

  • If we choose option 2b how do we avoid triggering a second episode of "rename-gate"? ie tons of irrational fear and confusion with trolls fanning the flames?

  • I propose making the monolith a library ("libmonolith"?) to avoid confusion with the docker engine daemon. It should be very easy to create an alternative to the current docker engine daemon with libmonolith. But it should not be that alternative otherwise somebody is bound to misunderstand and package it as a replacement or successor to the docjer daemon - which would be a bad idea since we are planning to gradually split it up and make it disappear.

@mlaventure

This comment has been minimized.

Copy link
Contributor

mlaventure commented Apr 28, 2017

@duglin

This comment has been minimized.

Copy link
Contributor

duglin commented Apr 28, 2017

yea right after I hit the "comment" button I realized that "ce" might be an issue, but at the same time I couldn't think of a good word other than "engine". I'm not a fan of "monolith" because I think in a few months that'll be incorrect and imply something negative.

@mlaventure

This comment has been minimized.

Copy link
Contributor

mlaventure commented Apr 28, 2017

@ijc

This comment has been minimized.

Copy link
Contributor

ijc commented Apr 28, 2017

WRT renaming and redirects currently most people are, I expect, using the github.com/docker/docker paths and since the move are now relying on the GH redirect from github.com/docker/docker to github.com/moby/moby.

If we now rename github.com/moby/moby to github.com/moby/sponge (I'm using sponge to avoid implicitly blessing any potential sensible names in my examples) then there will be a double redirect github.com/docker/dockergithub.com/moby/mobygithub.com/moby/sponge. We would need to be very sure that was going to work, except for the next point which makes it moot.

When we then create a new github.com/moby/moby then we would break the github.com/moby/mobygithub.com/moby/sponge redirect and therefore break the double chain from github.com/docker/docker to the code. So we would need to work with GH to change the existing github.com/docker/docker redirect to point to github.com/moby/sponge to coincide with the move.

@amirmc

This comment has been minimized.

Copy link

amirmc commented Apr 28, 2017

I think whatever gets decided we need to make sure there's a discussion with folks at GitHub to ensure the redirects, issues, forks, et. al. are all as we expect them to be. This is more than just an implementation detail and we should allow adequate time for it.

Regarding @shykes comment on avoiding 'rename-gate' I think we mitigate this by providing a clear explanation of what will be happening (in advance), why it is happening, when it will happen, and what a user needs to do (even if that's nothing). Some of this content already exists. This could be added clearly to the top of the readme and also link to an issue where items are getting checked off (that thread can be locked if you're worried about side discussions happening there).

@mavenugo

This comment has been minimized.

Copy link
Contributor

mavenugo commented Apr 28, 2017

@amirmc @ijc25 the fear of 'rename-gate' is real and as @shykes mentioned with the amount of irrational fear (and flames) IMO any amount of rational explanation and documentation will not help solve that. Hence, I think we must consider it as an important criteria.

Just a devil's advocate, why cant we all work on componentization and leave the monolith in its current place ? As maintainers, we have much better control over managing PRs and we can educate contributors to contribute patches to the right components during this transition phase. Also we can have appropriate tools / processes to know when the transition to proper components are complete and we can get rid of the monolith at that time.

Yes, it wont be clean and a lot of burden on maintainers and contributors. But, atleast we understand the problem better and we are in a better position to handle it.

@cpuguy83

This comment has been minimized.

Copy link
Contributor

cpuguy83 commented Apr 28, 2017

Agree, I'm not really in favor of moving this thing again.
We can add the moby tool package under cmd/ and gradually start moving the old docker/docker bits out.

@cpuguy83

This comment has been minimized.

Copy link
Contributor

cpuguy83 commented Apr 28, 2017

Btw, it's already in cmd/ in moby/tool anyway.

@vdemeester

This comment has been minimized.

Copy link
Member

vdemeester commented Apr 28, 2017

Agreeing with that too, it is going to take time ans be a little painful but I think it's the safe way 😇

@shykes

This comment has been minimized.

Copy link
Collaborator

shykes commented Apr 28, 2017

@tiborvass

This comment has been minimized.

Copy link
Collaborator

tiborvass commented Apr 28, 2017

Solution 1: Not changing anything but continuously update the README

  • Pros: simplest
  • Cons: confusion could still be greater than we’d like

Solution 2: Reorganizing to having as little top level folders as possible (api, client, pkg, engine) + continuously upadte the README

  • Pros: still quite simple, confusion is lessened, people not vendoring packages we moved will not be broken if they go get github.com/docker/docker/pkg/... and will not be more broken than they are today if they use go get github.com/moby/moby/pkg/....
  • Cons: docker/docker issues/PRs are still on moby/moby which could still contribute to confusion. Needs to update import paths which requires us to choose already between docker/docker and moby/moby (=> dependency on yesterday’s import paths issue), breaks those who are not vendoring packages we moved (if they use moby/moby URLs), needs updating many PRs

Solution 3: Moving the monolith with redirects

  • Pros: possibly solves the confusion the best with a new repo name, docker/docker issues and PRs in a repo not named moby
  • Cons: highest risk (needs GH involvement), although may create more confusion (too many changes)

I vote for solution 2.

@thaJeztah thaJeztah added the roadmap label Apr 29, 2017

@mlaventure

This comment has been minimized.

Copy link
Contributor

mlaventure commented May 1, 2017

Only Solution 2 or 3 make sense to me.

I'm fine with 2, all the docker / engine .md files needs to be mvoed away from the root and top level folders to at least avoid confusion since they actually don't apply to moby/moby.

@vieux

This comment has been minimized.

Copy link
Collaborator

vieux commented May 2, 2017

I think Solution 2 is a good middle ground. docker/docker issues/PRs will gradually be moved of the repo once we have a place for them (related to #32864)

@vdemeester

This comment has been minimized.

Copy link
Member

vdemeester commented May 2, 2017

I also think Solution 2 is a good middle ground and the less "disruptive" 👼

@cpuguy83

This comment has been minimized.

Copy link
Contributor

cpuguy83 commented May 2, 2017

+1 on solution 2
We need to communicate that github.com/moby/moby is not a valid import path, though.

@cpuguy83

This comment has been minimized.

Copy link
Contributor

cpuguy83 commented May 2, 2017

Discussed on today's standup we'll go with option 2.
I volunteered to handle this.
Plan is to move everything except api, pkg, and client to /mono

Note that import paths for these packages should remain at github.com/docker/docker and never github.com/moby/moby.

@thaJeztah

This comment has been minimized.

Copy link
Member

thaJeztah commented May 2, 2017

Bikeshed; possibly /runtime instead of /mono ? (I know the actual runtime is not in this repo, but it feels like a more accurate description than /mono, which is just "organisational")

@dnephin

This comment has been minimized.

Copy link
Member

dnephin commented May 2, 2017

More bikeshed: this has commonly been refered to as engine, so why not /engine ?

@cpuguy83

This comment has been minimized.

Copy link
Contributor

cpuguy83 commented May 2, 2017

Ultimately we want this entire package to just go away.
Calling it /engine or /runtime are very specific things and gives it a bit more stickiness.

@duglin

This comment has been minimized.

Copy link
Contributor

duglin commented May 2, 2017

Sorry, but /mono makes me think of mononucleosis :-) plus its not really meaningful to an outsider since its more of a historical statement than a "project purpose". What's the functional purpose of this repo at the end of all this work? Perhaps if people described what its supposed to do then a name will materialize.

I kind of view it as the integration point, but I also view it as the core engine - which is why I kind of liked "engine", even w/o the httpd layer since that was just an add-on in my head.

@cpuguy83

This comment has been minimized.

Copy link
Contributor

cpuguy83 commented May 2, 2017

@duglin Yes, pretty much intentional to make you think of mononucleosis.
The purpose of this package is to go away. Definitely not an integration point. More of a de-integration point.

@duglin

This comment has been minimized.

Copy link
Contributor

duglin commented May 2, 2017

LOL let's really make it bad then.... /herpes :-)

hmmm, de-integration? What would you call the component that manages the grpc interface for this disease?

@vieux vieux referenced this issue May 3, 2017

Open

Find a place for `/pkg` #32989

5 of 21 tasks complete

@cpuguy83 cpuguy83 referenced this issue May 4, 2017

Closed

Move the monolith #33022

2 of 3 tasks complete
@mavenugo

This comment has been minimized.

Copy link
Contributor

mavenugo commented Jul 23, 2017

Based on the discussion under https://forums.mobyproject.org/t/topic-find-a-good-and-non-confusing-home-for-the-remaining-monolith/37/54 and the clarity of the requirements :

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 current proposal is to rename the project name to moby/moby-core.

Such a rename and appropriate communication that go with it should help clarify any lingering confusion. We must take this opportunity to resolve go pkg issues such as #33989 and #32862 to avoid more confusions with such a migration.

@mavenugo mavenugo added priority/P1 and removed roadmap labels Jul 23, 2017

@stephenrwalli

This comment has been minimized.

Copy link

stephenrwalli commented Jul 25, 2017

FWIW: mono is Spanish for monkey. (We all learned this at the start of http://www.mono-project.com/ all those years ago.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment