-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[KEP-4639] Update CRI API and workflow #4751
Conversation
Can you fix typo in this example as well? enhancements/keps/sig-node/4639-oci-volume-source/README.md Lines 339 to 340 in 0c770bc
|
0c770bc
to
2305ba6
Compare
@toVersus sure, fixed as suggested 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seeing the move to reference in the pod spec.. Was the desire to move to using reference across the board as a more general term for these .. vs. ImageSpec image? If so maybe consider creating a ReferenceSpec type that is an ImageSpec type.. and using ReferenceSpec and reference in the message Mount{}
. Later we can add additional fields to specify the params for artifact types, etc.
Goal for this PR is to reflect the current as-is implementation per https://github.com/kubernetes/cri-api/blob/a17496fa80c15a582444f49c77d019fced169e77/pkg/apis/runtime/v1/api.proto#L247-L255, we can add future enhancements on top of that later on, sure. |
ok |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can/should we normalize the terminology used? The terminology used varies from OCI reference as an "image or artifact", OCI "object(s)", OCI "image", and OCI "artifact."
It's not clear if we are removing artifacts for this cycle and only implementing OCI image as is (including platform index selected images).. or keeping artifact typed OCI mages as a stretch goal ...
IOW when we just say OCI image do we mean "image or artifact" and when we say OCI object do we mean "one conceptual piece of content stored as blobs with an accompanying manifest, where manifest is a JSON document uploaded via the manifests endpoint." Object being the broadest term implying any manifest type. Image or Artifact implying an image manifest (selected or not from a platform index) or "content other than OCI container images .. packaged using the image manifest."
The KEP should follow the proposed vocabulary: enhancements/keps/sig-node/4639-oci-volume-source/README.md Lines 278 to 297 in 7c97898
Means that "OCI images and/or artifacts" are "OCI objects", while "OCI images" alone mostly refer to the existing implementation. |
Updating the KEP after the merge of: kubernetes/kubernetes#125659 This reflects the current state of the enhancement. Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
2305ba6
to
11ea92b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
ea1e7d0
to
23105e9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mikebrow, mrunalp, saschagrunert The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Updating the KEP after the merge of: kubernetes/kubernetes#125659
This reflects the current state of the enhancement.
Refers to #4639
PTAL @haircommander @mikebrow @mrunalp