Update docker registry package

[0xmichalis]

https://github.com/docker/distribution/releases

When that time comes, code.google.com/p/go-uuid/uuid which is a duplicate of https://github.com/pborman/uuid can be removed from our deps.

[0xmichalis]

When that time comes, code.google.com/p/go-uuid/uuid which is a duplicate of https://github.com/pborman/uuid can be removed from our deps.

Of course some imports in our codebase need to change.

[ncdc]

We can't bump docker/distribution until we refactor image pruning (#3333) due to some hacks we made to the distribution Godep that are very difficult to carry forward with the latest upstream code.

[smarterclayton]

Do we have adequate attention on making sure this lands as fast as is possible? This is now a serious blocking issue for a huge number of issues.

[ncdc]

We still need an upstream PR merged before we can proceed, plus code review on the origin changes.

[smarterclayton]

Timeframe on upstream pr?

[ncdc]

I just asked for an update; not sure at this point.

[pweil-]

linking the upstream: distribution/distribution#1050

[pweil-]

distribution/distribution#1050 is still under review. It may have a chance at getting merged this week but I don't think we can guarantee it. Given that this is a P0 should we proceed with trying to carry the pruning hacks and resolving this or continue to wait on the upstream PR?

[ncdc]

👎 to carrying hacks - we've learned our lesson the hard way 😢

[smarterclayton]

We are falling really far behind on the registry. I think we can't afford
to keep falling behind. Can we asses the risk of the rebase in terms of
possibility of breakage of end user workflows?

On Dec 8, 2015, at 10:33 AM, Andy Goldstein [email protected]
wrote:

[image: 👎] to carrying hacks - we've learned our lesson the hard way [image:
😢]

—
Reply to this email directly or view it on GitHub
#4339 (comment).

[ncdc]

The only thing we have to deal with is pruning and possibly the custom
/healthz handler I hacked in. I believe the latest registry code responds
200 at / now, which is a sufficient replacement for /healthz. So that just
leaves pruning, which depends on upstream 1050 which isn't in yet.

On Wednesday, December 9, 2015, Clayton Coleman [email protected]
wrote:

We are falling really far behind on the registry. I think we can't afford
to keep falling behind. Can we asses the risk of the rebase in terms of
possibility of breakage of end user workflows?

On Dec 8, 2015, at 10:33 AM, Andy Goldstein <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');>
wrote:

[image: 👎] to carrying hacks - we've learned our lesson the hard way
[image:
😢]

—
Reply to this email directly or view it on GitHub
#4339 (comment).

—
Reply to this email directly or view it on GitHub
#4339 (comment).

[miminar]

I believe the latest registry code responds 200 at / now

Correct.

So that just leaves pruning, which depends on upstream 1050 which isn't in yet.

I'd rather rework pruning after the rebase itself (with or without 1050 carried on top). Doing it together would result in unreviewable PR like the last time. We could rebase on top of registry:v2.2.0 or registry:2.2.1 which is due by December 9, 2015.

Other note-able changes:

• repository name components can now be one character long
• error messages were reworked
• new features (v2.1, v.2.2) like support for repo listing and pagination, new backend drivers, pull-through-cache, communication via unix-socket

Those shouldn't break existing workflows.

[miminar]

Upstream wants to refactor manifest interface before accepting anything else, which means another not-so-short delay for 1050.

[smarterclayton]

Which means... We have to carry 1050 if we want to upgrade docker? Right
now it seems we have all the cost without even getting a new registry
version. Do we need to release the registry image on a different window
than 3.1.1 in order to get enough time to get this work done?

On Dec 10, 2015, at 3:09 AM, Michal Minar [email protected] wrote:

Upstream wants to refactor manifest interface before accepting anything
else, which means another not-so-short delay for 1050.

—
Reply to this email directly or view it on GitHub
#4339 (comment).

[miminar]

Yes, we have to carry 1050 if we want to rebase the registry. I don't think 1050 makes it before 3.1.1. Last time I asked upstream, they told me they want to merge it before refactoring. Now they change their mind. So it's really hard to guess. I'll ask them on ETA of the refactoring.

[smarterclayton]

Can you make 1050 carry + rebase happen for 3.1.1? Risk profile sounded
less than I was worried about.

On Thu, Dec 10, 2015 at 9:40 AM, Michal Minar [email protected]
wrote:

Yes, we have to carry 1050 if we want to rebase the registry. I don't
think 1050 makes it before 3.1.1. Last time I asked upstream, they told me
they want to merge it before refactoring. Now they change their mind. So
it's really hard to guess. I'll ask them on ETA of the refactoring.

—
Reply to this email directly or view it on GitHub
#4339 (comment).

[miminar]

@smarterclayton Sure. Working on it.

[miminar]

@smarterclayton: Rebased docker/distribution (PR #5404) resurrected.