Story #3401
closedCreate content models for pulp_docker 4.0
100%
Description
Manifest(Content) models a docker manifest:
- digest: CharField(255, db_index=True, unique=True)
- schema_version: IntegerField()
- media_type: CharField(choices=)
media_type choices:
- application/vnd.docker.distribution.manifest.v1+json
- application/vnd.docker.distribution.manifest.v2+json
ManifestBlob(Content) models the relationship between Manifests and Blobs. Each blob is stored as an Artifact and is related by ContentArtifact.
- digest: CharField(max_length=255, db_index=True, unique=True)
- manifest: ForeignKey(Manifest, related_name='blobs', on_delete=CASCADE)
- media_type: CharField(choices=)
media_type choices:
- application/vnd.docker.container.image.v1+json - Container config json represented as a blob
- application/vnd.docker.image.rootfs.diff.tar.gzip - Regular blob
- application/vnd.docker.image.rootfs.foreign.diff.tar.gzip - Foreign blob ( we do not intend to store foreign blobs. Docker client during pull will fetch it from the remote location)
ManifestList(Content) models a docker manifest-list.
- digest: CharField(max_length=255, db_index=True, unique=True)
- schema_version: IntegerField()
- manifests: ManyToManyField('Manifest', through='ManifestListManifest')
- media_type: CharField(choices=)
media_type choices:
- application/vnd.docker.distribution.manifest.list.v2+json
ManifestListManifest - models the many-to-many relationship between Manifest and ManifestList.
- manifest: ForeignKey(Manifest, related_name='manifests', on_delete=CASCADE)
- manifest_list: ForeignKey(ManifestList, related_name='manifest_lists', on_delete=CASCADE)
- architecture: CharField(255)
- os: CharField(255)
- os_version: charField(255)
- os_features: TextField()
- variant: CharField(255)
- features: TextField()
Tag(Content)
- name CharField(255, db_index=True)
- manifest ForeignKey(Manifest, null=True, related_name='tags', on_delete=CASCADE)
- manifest_list ForeignKey(ManifestList, null=True, related_name='tags', on_delete=CASCADE)
unique_together = (name, manifest)
unique_together = (name, manifest_list)
Design assumptions:
- Pre-save validation on the model ensures that one-of but not both manifest and manifest_list are set.
- Tag name uniqueness and referential integrity{1} will be enforced by the plugin. During sync, this happens in the task logic. For content add/remove API calls, this happens in the (docker specific) view. Both can re-use the same code.
[1] Tag referential integrity is ensuring that when a manifest or manifest_list is removed from a repository, referencing tags are also removed. Also, when a tag is added to a repository, referenced manifest or manifest_list are also added.
This story will be complete when CRUD is possible for Manifests (for this story, the metadata is not expected to be extracted from the file, but provided by the user in the request body.)
Related issues
Updated by ipanova@redhat.com over 6 years ago
before hardcoding the digest using sha256 hashing algoritm, i'd like to confirm that it is indeed so.
There are the docs, [0] but i don't believe them. I'd look into the code
[0] https://docs.docker.com/registry/spec/api/#content-digests
Updated by bizhang over 6 years ago
- Description updated (diff)
Updated length of digest field, since sha512 might be supported
Updated by bizhang over 6 years ago
- Subject changed from Create Image Manifest Models for pulp_docker 4.0 to Create Manifest Models for pulp_docker 4.0
- Description updated (diff)
Updated by ipanova@redhat.com over 6 years ago
there can be a signed manifest application/vnd.docker.distribution.manifest.v1+prettyjws, we need to investigate on this, and extend the choice field in the Manifest model.
Updated by ipanova@redhat.com over 6 years ago
I gave some more thought to the mediatype field. Do we really want to have it on the model?
Image manifest schema2 does have this in the json file, meanwhile image manifest schema 1 does not. The only way to figure out what's the mediaType of the schema 1( signed or not) is to check the response headers.
https://docs.docker.com/registry/spec/manifest-v2-1/#manifest-field-descriptions
https://docs.docker.com/registry/spec/manifest-v2-2/#image-manifest-field-descriptions
In case we'd decide to remove this field from the model, i would do the same for ManifestList, for consistency.
Updated by ipanova@redhat.com over 6 years ago
- Sprint Candidate changed from No to Yes
Updated by amacdona@redhat.com over 6 years ago
- Subject changed from Create Manifest Models for pulp_docker 4.0 to Create Manifest Model, ViewSet, Serializer for pulp_docker 4.0
- Description updated (diff)
Updated by amacdona@redhat.com over 6 years ago
We only need schema 2 for MVP. But please namespace this appropriately to later add schema 1.
Namespace meaning model and vs endpoint?
Updated by jortel@redhat.com about 6 years ago
- Blocked by Task #3398: Make pulp_docker/4.0-dev branch ready for plugin development added
Updated by jortel@redhat.com about 6 years ago
- Blocks Task #3950: Tag model added
Updated by jortel@redhat.com about 6 years ago
- Status changed from NEW to ASSIGNED
- Assignee set to jortel@redhat.com
Updated by jortel@redhat.com about 6 years ago
- Subject changed from Create Manifest Model, ViewSet, Serializer for pulp_docker 4.0 to Create content models for pulp_docker 4.0
- Description updated (diff)
Updated by jortel@redhat.com about 6 years ago
- Status changed from ASSIGNED to POST
Updated by jortel@redhat.com about 6 years ago
- Blocks Story #3989: Create content model serializers and viewsets for pulp_docker 4.0 added
Updated by jortel@redhat.com about 6 years ago
Do we really want to use choices= in the CharField for media_type? Bounding the permitted value seems like a better fit for the ViewSet. Or, was the intent to store encoded values to be translated by the field?
Thoughts?
Updated by amacdona@redhat.com about 6 years ago
A choice field seems appropriate to me, because there are a finite set of acceptable values. @jortel, I might be missing something, why would we want to restrict these choices on the ViewSet and allow invalid choices in the db?
Updated by jortel@redhat.com about 6 years ago
Certainly I agree that it would be best for the field to perform the validation.
However, the choices= parameter seems to be geared for value translation rather than field validation. I get this impression mainly because choices takes a list of tuples (actual-value, human-readable). Also, it's my understanding that field validation only get's invoked by one of the clean() methods which are not called on Model.save(). Best I can tell, the clean() methods only get called from ModelForm which I don't think we're using.
I'm likely wrong about how django works here. The docs are a little unclear. :)
Can someone confirm that using the choices= in this way (in pulp) will result in enforced field validation?
https://docs.djangoproject.com/en/2.1/ref/models/fields/#choices
https://docs.djangoproject.com/en/2.1/ref/models/instances/#validating-objects
Added by jortel@redhat.com about 6 years ago
Added by jortel@redhat.com about 6 years ago
Revision 4c5cd707 | View on GitHub
Add docker content models. closes #3401
Added by jortel@redhat.com about 6 years ago
Revision 4c5cd707 | View on GitHub
Add docker content models. closes #3401
Added by jortel@redhat.com about 6 years ago
Revision 4c5cd707 | View on GitHub
Add docker content models. closes #3401
Updated by jortel@redhat.com about 6 years ago
- Status changed from POST to MODIFIED
- % Done changed from 0 to 100
Applied in changeset 4c5cd707751a1e69d04d9e1e79fb2e2b8aaf5d6f.
Updated by amacdona@redhat.com almost 6 years ago
- Blocks deleted (Task #3950: Tag model)
Updated by amacdona@redhat.com almost 6 years ago
- Has duplicate Task #3950: Tag model added
Updated by ipanova@redhat.com about 5 years ago
- Project changed from Docker Support to Container Support
Updated by ipanova@redhat.com almost 5 years ago
- Status changed from MODIFIED to CLOSED - CURRENTRELEASE
Add docker content models. closes #3401