-
Notifications
You must be signed in to change notification settings - Fork 585
Add ImageContentSourcePolicy to operator/v1alpha1 #354
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,54 @@ | ||
| package v1alpha1 | ||
|
|
||
| import metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" | ||
|
|
||
| // +genclient | ||
| // +genclient:nonNamespaced | ||
| // +k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object | ||
|
|
||
| // ImageContentSourcePolicy holds cluster-wide information about how to handle registry mirror rules. | ||
| // When multple policies are defined, the outcome of the behavior is defined on each field. | ||
| type ImageContentSourcePolicy struct { | ||
| metav1.TypeMeta `json:",inline"` | ||
| // Standard object's metadata. | ||
| metav1.ObjectMeta `json:"metadata,omitempty"` | ||
|
|
||
| // spec holds user settable values for configuration | ||
| // +required | ||
| Spec ImageContentSourcePolicySpec `json:"spec"` | ||
| } | ||
|
|
||
| // ImageContentSourcePolicySpec is the specification of the ImageContentSourcePolicy CRD. | ||
| type ImageContentSourcePolicySpec struct { | ||
| // repositoryDigestMirrors allows images referenced by image digests in pods to be | ||
| // pulled from alternative mirrored repository locations. The image pull specification | ||
| // provided to the pod will be compared to the source locations described in RepositoryDigestMirrors | ||
| // and the image may be pulled down from any of the repositories in the list instead of the | ||
| // specified repository allowing administrators to choose a potentially faster mirror. | ||
| // Only image pull specifications that have an image disgest will have this behavior applied | ||
| // to them - tags will continue to be pulled from the specified repository in the pull spec. | ||
| // When multiple policies are defined, any overlaps found will be merged together when the mirror | ||
| // rules are written to `/etc/containers/registries.conf`. For example, if policy A has sources `a, b, c` | ||
| // and policy B has sources `c, d, e`. Then the mirror rule written to `registries.conf` will be `a, b, c, d, e` | ||
| // where the duplicate `c` is removed. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This comment is fine for now, I'm ok with discussing the policy in a follow up before 4.2 GA but after this feature has been prototyped. |
||
| // +optional | ||
| RepositoryDigestMirrors []RepositoryDigestMirrors `json:"repositoryDigestMirrors"` | ||
| } | ||
|
|
||
| // +k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object | ||
|
|
||
| // ImageContentSourcePolicyList lists the items in the ImageContentSourcePolicy CRD. | ||
| type ImageContentSourcePolicyList struct { | ||
| metav1.TypeMeta `json:",inline"` | ||
| // Standard object's metadata. | ||
| metav1.ListMeta `json:"metadata"` | ||
| Items []ImageContentSourcePolicy `json:"items"` | ||
| } | ||
|
|
||
| // RepositoryDigestMirrors holds cluster-wide information about how to handle mirros in the registries config. | ||
| // Note: the mirrors only work when pulling the images that are reference by their digests. | ||
| type RepositoryDigestMirrors struct { | ||
| // sources are repositories that are mirrors of each other. | ||
| // +optional | ||
| Sources []string `json:"sources,omitempty"` | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This needs to be a list of lists, the parent (in ImageContentSource.Spec) should be an array (instead of a nested struct).
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Fixed, made
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
…
(I know very little about k8s API conventions): Isn’t a list of objects that contains a list of entries unnecessarily too much to iterate over? If a client can create multiple instances of Is there a semantic difference between a set of specs vs a single spec with an array?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We don't force denormalization of ImageContentSourcePolicy-like objects into multiple objects because that puts an extra burden on users/integrators. The atomic unit of transaction is a single object in etcd, and so someone who wishes to add / remove a strict policy will naturally do so via GET/PUT operations on a single resource, where they can ensure the policy matches the desired state. |
||
| } | ||
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
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.
Any other possible names we could use? Policy is fairly common. Is
content sourcethe best name? I don't want to be specific about "mirroring" or "disconnected", so trying out a name that implies "you can change where we source images" was the initial argument.Maybe future might be "you have to have signatures from X for Y"
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.
Just
ImageContentSourceorImageSources?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.
Changed it to
ImageContentSourceThere 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.
By "policy is fairly common" I meant "It's good to have Policy in there to distinguish this from a more concrete object". I don't think you have to change the name, just want to see some suggestions about what names could be that better describe what this object does.
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.
changed the name back
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.
You’re right that “content source” is not a commonly used term for this. I’d just say one of “image {repositories,locations,(servers,storage?)}”; the “content” word adds nothing.
Per #354 (comment):
do we want this to be generic for all kinds of images, or actually say something entirely specific to the contemplated use, in the ballpark of
OpenShiftReleasedImageLocations?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.
I think making it generic will allow us to reuse it for other use cases in the future.
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.
The resource group usually contains the product namespace (operator.openshift.io) so it is redundant in the title.