Story #2189
closed
As a user, I can update docker_tag units without using sync
Added by twaugh over 7 years ago. Updated about 5 years ago.
100%
Description
When there are multiple docker_manifest units in a repository all sharing the same tag name, and a docker_tag unit referencing one of those manifests, it should be possible to update that docker_tag unit to refer to a different docker_manifest unit already in the repository (one which has the correct tag).
When there is a docker_manifest unit in the repository but no docker_tag unit for it (perhaps because it or its manifest has previously been deleted), it should be possible to create a docker_tag unit for that manifest.
Currently these operations are only possible with the help of an external docker v2 registry, and using the disassociate and sync operations.
Updated by dkliban@redhat.com over 7 years ago
- Sprint Candidate changed from No to Yes
- Tags 2.11 added
Updated by mhrivnak over 7 years ago
Presumably this would be facilitated with an upload. The uploaded tag would replace one currently in the repo, with the same logic used when copying into a repo.
Updated by mhrivnak over 7 years ago
- Description updated (diff)
- Groomed changed from No to Yes
Updated by ipanova@redhat.com over 7 years ago
I would suggest remove the 'As a user, I can create a new Tag unit' because Tag unit cannot exist only by itself, it should be associated to a manifest. Instead I would suggest rename story entirely to : 'As a user I can tag a manifest'
We could have something like:
pulp-admin docker repo tag --repo-id synctest --tag-name glibc --manifest-digest sha256:3e00695ae65afe08d3cc4e1c0bc4efb335e9c158c9b5a5f7c045c9ec380c731b
This command will:
1) in case manifest missed tag before - create a new tag and associate it to a manifest.
By this i mean:
- a new tag unit is created
2) in case manifest previously had a tag, it will be replaced with a new one.
By this i mean:
- a new tag unit is created
- old unit tag is removed( since tag references a single manifest)
- tag model field 'manifest_digest' is updated with new digest
Updated by mhrivnak over 7 years ago
- Groomed changed from Yes to No
The manifest contents cannot be changed. They are immutable, and it's important to preserve that because they can be signed. If we change the content, such as the tag name embedded in the manifest, that also would change the digest.
Schema 2 removed the tag name from the manifest, and it sounds like docker is already ignoring the value in schema 1 manifests. So it's theoretically ok to have a tag object referencing a manifest with a name that's different than the one that's embedded in the manifest.
That said, I'm fine with adjusting the wording of the story. From the user perspective, you're exactly right that they just want to tag a manifest. They want the operation to make the right choice to either change the value of an existing tag, or create a new tag. I'll adjust the two checklist items I added to make them less user-centric. Let me know if you like that better.
What does your checklist item "change code accordingly so api call also works" mean?
Updated by ipanova@redhat.com over 7 years ago
mhrivnak wrote:
Schema 2 removed the tag name from the manifest, and it sounds like docker is already ignoring the value in schema 1 manifests. So it's theoretically ok to have a tag object referencing a manifest with a name that's different than the one that's embedded in the manifest.
This clarifies a lot of things, thanks.
What does your checklist item "change code accordingly so api call also works" mean?
well, make it work both api+cli. Feel free to re-phrase it
Updated by twaugh over 7 years ago
Incidentally, when I filed this the use-case I was thinking of was that there are already several manifests present with the same tag (e.g. 'latest'), and I want to be able to choose which one is reachable by its tag.
Updated by daviddavis over 7 years ago
Just to confirm: I'm guessing there should be some validation when a user tries to update a tag and points it at a manifest whose tag field does not match the tag name?
If I add this sort of validation, I'll add a TODO to remove it when we move to schema 2.
Nevermind, I see @mhrivnak's comment.
Added by daviddavis over 7 years ago
Added by daviddavis over 7 years ago
Revision 907850aa | View on GitHub
Add docker command to point a tag to manifest
Adding a command that will update a tag to point a manifest given a digest. If the tag does not exist, this command will create it. The options are repo id, tag name, and manifest digest.
Added by daviddavis over 7 years ago
Revision 907850aa | View on GitHub
Add docker command to point a tag to manifest
Adding a command that will update a tag to point a manifest given a digest. If the tag does not exist, this command will create it. The options are repo id, tag name, and manifest digest.
Added by daviddavis over 7 years ago
Revision 907850aa | View on GitHub
Add docker command to point a tag to manifest
Adding a command that will update a tag to point a manifest given a digest. If the tag does not exist, this command will create it. The options are repo id, tag name, and manifest digest.
Updated by daviddavis over 7 years ago
- Status changed from ASSIGNED to MODIFIED
- % Done changed from 0 to 100
Applied in changeset 907850aa999e94c1337ff280365f0d350b981231.
Updated by semyers over 7 years ago
- Status changed from 5 to CLOSED - CURRENTRELEASE
.
Add docker command to point a tag to manifest
Adding a command that will update a tag to point a manifest given a digest. If the tag does not exist, this command will create it. The options are repo id, tag name, and manifest digest.
closes #2189 https://pulp.plan.io/issues/2189