Docker Support

The suggested change didn't fix the problem.
/v2/<repo>/manifests/latest from Crane disagrees with the Docker Distribution instance after a 'sync' and 'publish'.

Removing those lines did change which 'latest' I saw, but it still wasn't the right one. :-)

rbarlow wrote:

You will need to also remove the images from the repository and then resync and republish.

I really don't understand why the operation is called sync then. As I understand synchronization it should be an operation which makes content of two repositories identical -- something like `rsync --delete`. Why should be users responsible for managing the actual synchronization?

The way I would solve this is to make the process configurable:

• add an option to control overwriting
• add an option to delete content

I understand how that term could be interpreted differently. Perhaps a different word than "sync" should have been chosen, but the choice was made years ago, and we're not in a position right now to change it.

Pulp's sync workflow will continue to be additive by default. When new content appears in the remote feed, pulp will add it locally. When remote content disappears, pulp will retain that content. This is an important behavior that our users depend on.

Some content types have additional options to control and modify this behavior, and we're happy to consider adding something like that to the docker sync.

mhrivnak wrote:

Pulp's sync workflow will continue to be additive by default. When new content appears in the remote feed, pulp will add it locally. When remote content disappears, pulp will retain that content. This is an important behavior that our users depend on.

Okay, I understand that if this feature is in pulp for years.

It would be really beneficial for us to have those two options implemented. Especially the content overwriting -- the reason why Tim created this issue.

Checking in on this issue. Can you confirm that the changes requested will be prioritized or let us know if we need to have more conversations? This will be a blocker for Chain Rebuilds which is required by product management asap.

acarter@redhat.com wrote:

Checking in on this issue. Can you confirm that the changes requested will be prioritized or let us know if we need to have more conversations?

It's high on my priority list. I will probably get to it in the next two weeks. In the meantime I believe the deleting those lines will work around the issue, though I will likely solve the problem a different way.

This sounds like the right direction to me.

With the ability to upload Tag units, why would the user need to specify a name for the tag? Just because pulp_docker doesn't parse the Manifest? They won't want to create a Tag with a name different from what the Manifest says is its tag.

Also, to clarify: the Tag units will only be for V2 repositories?

twaugh wrote:

With the ability to upload Tag units, why would the user need to specify a name for the tag? Just because pulp_docker doesn't parse the Manifest? They won't want to create a Tag with a name different from what the Manifest says is its tag.

Hahaha, that is a great point! I'll make it so you just need to give the digest that you want to tag, and the Tag will automatically get the name from it. My excuse is that I didn't have my coffee yet this morning when I wrote this.

Also, to clarify: the Tag units will only be for V2 repositories?

Correct, we do not wish to alter the v1 workflow if possible.

I moved this back to modified, as we agreed that this would only be done in upstream pulp_docker.