Transfer to moby/moby

[cpuguy83]

It was brought up on the maintainers chat that we should probably merge libnetwork back into moby/moby. This would simplify vendoring/import issues and contributions.

/cc @thaJeztah @justincormack @AkihiroSuda

[cpuguy83]

We should think about how we can migrate issues/PR's (and what should just be closed/merged before doing so).

@AkihiroSuda mentioned that we could transfer libnetwork to the moby org first, this would allow us to transfer the issues to the moby/moby repo after the codebase is re-integrated with moby/moby.

[arkodg]

PTAL @mavenugo

[mavenugo]

Yes. This is a good idea. am a 👍 to this proposal.

[selansen]

been talking about it for very long time. It will save lot of time.

[thaJeztah]

generally 👍

first moving the repo to the moby org sounds good.

we should spend some time to go through pull requests that are open to see if there's ones that we want to have

before integrating the code into moby/moby;

• I'd love to see https://github.com/docker/libnetwork/pull/2509 (and related) in, so that we have less technical debt from the start
• we need to see what integration tests are in this repo, and if we need to rewrite those so that they can run in moby CI (or if they're already covered otherwise)
• we may keep the repository around (as in "not archived") as long as 19.03 is still actively maintained
• What works best for Mirantis (enterprise releases)? Keep this repo around, or create a fork in the Mirantis org and do backporting there?

[thaJeztah]

I noticed that kubernetes is vendoring libnetwork, so we need to make sure we don't break them (and make it easy to vendor the parts they need)

[justincormack]

Nothing should break in short term due to redirects. Why is k8s vendoring libnetwork anyway!!

I am going to mover this to moby org.

[cpuguy83]

It's importing ipvs code from here.

[justincormack]

Done. (the move, reopened for the merge into moby/moby).

[thaJeztah]

/cc @dims (for kubernetes)

[dims]

🙏 @thaJeztah

[dims]

yep, we use it for ipvs - https://cs.k8s.io/?q=github.com%2Fdocker%2Flibnetwork&i=nope&files=%5Epkg&repos=kubernetes/kubernetes

[cpuguy83]

Seems like a good candidate to move to separate repo.

[dims]

@cpuguy83 @thaJeztah @mavenugo @justincormack - so for a while, in kubernetes/kubernetes we have been trying to remove direct references to docker/docker (or moby/moby), splitting out the dockershim (or at least limiting its use in specific packages optionally imported) would take a whole bunch of references out, So that was our main thrust. But we still had a whole bunch of references to docker/docker. Over a period of time we have been able to prune the usage. Doing what is proposed here would be going backwards for us unfortunately.

I'd go further to request that we split out additional stuff from docker/docker (or moby/moby) into a library namely the sysinfo/parsers:

└── pkg
    ├── parsers
    │   ├── kernel
    │   └── operatingsystem
    └── sysinfo

used by cadvisor (https://cs.k8s.io/?q=pkg%2Fparsers&i=nope&files=.*%5C.go&repos=kubernetes/kubernetes)

and another package for terminal stuff:

└── pkg
    └── term
        └── windows

used directly by kubernetes CLI (https://cs.k8s.io/?q=pkg%2Fterm&i=nope&files=.*%5C.go&repos=kubernetes/kubernetes)

cc @liggitt

[cpuguy83]

@dims If we move ipvs out of libnetwork to a separate repo, you should be able to consume just the ipvs package.

[dims]

@cpuguy83 yep, that works!