Conversation
✅ Deploy Preview for olmv1 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
There was a problem hiding this comment.
Pull request overview
Adds support for user-defined spec.progressionProbes on ClusterExtensionRevision to gate phase progression based on custom assertions against rendered objects, with accompanying CRD/applyconfig updates and new e2e scenarios.
Changes:
- Extend
ClusterExtensionRevisionSpecwithprogressionProbesAPI types + deepcopy/applyconfig support. - Add CRD schema for
progressionProbesto experimental manifests/Helm CRD. - Update the controller to build and attach user-defined progression probes to the boxcutter progress probe chain; add e2e scenarios for pass/fail behavior.
Reviewed changes
Copilot reviewed 13 out of 13 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| test/e2e/features/revision.feature | Adds e2e scenarios covering progression probe pass/fail behavior (currently tagged @WIP). |
| manifests/experimental.yaml | Updates experimental CRD schema to include spec.progressionProbes. |
| manifests/experimental-e2e.yaml | Updates e2e experimental CRD schema to include spec.progressionProbes. |
| internal/operator-controller/controllers/clusterextensionrevision_controller.go | Builds user probes from spec.progressionProbes and adds them to the progress probe chain. |
| helm/olmv1/base/operator-controller/crd/experimental/olm.operatorframework.io_clusterextensionrevisions.yaml | Updates Helm CRD schema with spec.progressionProbes. |
| applyconfigurations/utils.go | Registers apply-configuration kinds for the new embedded types. |
| applyconfigurations/api/v1/progressionprobe.go | Generated apply-configuration for ProgressionProbe. |
| applyconfigurations/api/v1/probeselector.go | Generated apply-configuration for ProbeSelector. |
| applyconfigurations/api/v1/probeassertion.go | Generated apply-configuration for ProbeAssertion. |
| applyconfigurations/api/v1/fieldvalueprobe.go | Generated apply-configuration for FieldValueProbe. |
| applyconfigurations/api/v1/clusterextensionrevisionspec.go | Adds apply-configuration support for spec.progressionProbes. |
| api/v1/zz_generated.deepcopy.go | Adds deepcopy support for the new API structs/fields. |
| api/v1/clusterextensionrevision_types.go | Introduces the new API types and spec.progressionProbes. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
internal/operator-controller/controllers/clusterextensionrevision_controller.go
Outdated
Show resolved
Hide resolved
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #2550 +/- ##
==========================================
- Coverage 68.60% 67.80% -0.81%
==========================================
Files 131 137 +6
Lines 9330 9526 +196
==========================================
+ Hits 6401 6459 +58
- Misses 2438 2572 +134
- Partials 491 495 +4
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
3e0efb5 to
c1ddbb3
Compare
c1ddbb3 to
d1436fd
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 18 out of 18 changed files in this pull request and generated 7 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
...operator-controller/crd/experimental/olm.operatorframework.io_clusterextensionrevisions.yaml
Outdated
Show resolved
Hide resolved
d1436fd to
f905c9e
Compare
f905c9e to
ca1b6be
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 19 out of 19 changed files in this pull request and generated 3 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
internal/operator-controller/controllers/clusterextensionrevision_controller.go
Outdated
Show resolved
Hide resolved
camilamacedo86
left a comment
There was a problem hiding this comment.
That seems great, but would be nice if we can:
a) Address as much as possible the issues reported by kube-lint-api
b) Address the Copilot comments as well. Seems that we have a few ones that are valid.
Could you please look on those?
|
|
||
|
|
||
|
|
||
|
|
There was a problem hiding this comment.
Why do we have those spaces ?
Was this doc generated with the tooling used or API?
There was a problem hiding this comment.
This is auto-generated, so I don't know why it's adding these spaces...
internal/operator-controller/controllers/clusterextensionrevision_controller.go
Outdated
Show resolved
Hide resolved
ca1b6be to
a68ec4b
Compare
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
a68ec4b to
100629d
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 19 out of 19 changed files in this pull request and generated 4 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
internal/operator-controller/controllers/clusterextensionrevision_controller.go
Outdated
Show resolved
Hide resolved
internal/operator-controller/controllers/clusterextensionrevision_controller.go
Outdated
Show resolved
Hide resolved
internal/operator-controller/controllers/clusterextensionrevision_controller.go
Outdated
Show resolved
Hide resolved
100629d to
b230589
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 19 out of 19 changed files in this pull request and generated 3 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
internal/operator-controller/controllers/clusterextensionrevision_controller.go
Show resolved
Hide resolved
internal/operator-controller/controllers/clusterextensionrevision_controller.go
Show resolved
Hide resolved
internal/operator-controller/controllers/clusterextensionrevision_controller.go
Outdated
Show resolved
Hide resolved
d1cb7c5 to
c66ea0f
Compare
|
@JoelSpeed would you mind taking a look at these API changes? We'd really appreciate it! |
c66ea0f to
66b8345
Compare
66b8345 to
b7a4a28
Compare
There was a problem hiding this comment.
Copilot reviewed 19 out of 19 changed files in this pull request and generated 2 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
internal/operator-controller/controllers/clusterextensionrevision_controller.go
Show resolved
Hide resolved
b7a4a28 to
e00edb6
Compare
Hi @dfranz that is amazing
Just one detail, should not all be marked with // opcon:experimental
Is not all experimental ? Beyond that LGTM
e00edb6 to
e30eea0
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 19 out of 19 changed files in this pull request and generated 4 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
internal/operator-controller/controllers/clusterextensionrevision_controller.go
Show resolved
Hide resolved
internal/operator-controller/controllers/clusterextensionrevision_controller.go
Show resolved
Hide resolved
| // +optional | ||
| // +unionMember | ||
| // <opcon:experimental> | ||
| GroupKind metav1.GroupKind `json:"groupKind,omitempty,omitzero"` |
There was a problem hiding this comment.
I would use here our own type, not the one from k8s. this protect us from upstream changes that could change our api by upgrading dependencies.
There was a problem hiding this comment.
We do the same with Conditions, TypeMeta, and ObjectMeta. Are any of these likely to get updated? And if they did get changed upstream, couldn't we just recreate the format and preserve the API when we bump the version?
There was a problem hiding this comment.
With our own types, especially under .spec we have more control. But you can consider this as a nit.
| // +optional | ||
| // +unionMember | ||
| // <opcon:experimental> | ||
| Label metav1.LabelSelector `json:"label,omitempty,omitzero"` |
There was a problem hiding this comment.
It's pretty standard to leverage label selector in this way, I suspect we will be ok leverage the metav1 types in this spec
| // +listType=atomic | ||
| // +optional | ||
| // <opcon:experimental> | ||
| ProgressionProbes []ProgressionProbe `json:"progressionProbes,omitempty"` |
There was a problem hiding this comment.
Given that in the documentation above we speak about readiness probes, why do not we call this field and the corresponding type ReadinessProbes?
There was a problem hiding this comment.
The probes can be considered readiness probes, but their main purpose is to halt or continue the progression of the phases being rolled out. Calling the entire thing ReadinessProbes to me sounds like we're only setting rules to set the whole revision as Ready.
There was a problem hiding this comment.
Alright, but then we should carefully document it what it does and what are the implications on the rollout.
| // +kubebuilder:validation:Enum=Condition;FieldsEqual;FieldValue | ||
| // +required | ||
| // <opcon:experimental> | ||
| ProbeType ProbeType `json:"type,omitempty"` |
There was a problem hiding this comment.
We have several union discriminators set across our API, they should all have unique names to distinguish which discriminator the type is being used for.
There was a problem hiding this comment.
We have several union discriminators set across our API, they should all have unique names to distinguish which discriminator the type is being used for.
I am not sure if understand: we serialize this into JSON/Yaml as type, why we cannot refer it go code as Assertion.Type?
There was a problem hiding this comment.
Ah I see what you mean; I thought you meant the type name, not the field name. Yes we can just name it that 👍
| // +unionMember | ||
| // +optional | ||
| // <opcon:experimental> | ||
| Condition ConditionProbe `json:"condition,omitempty,omitzero"` |
There was a problem hiding this comment.
do we really need both omitempty and omitzero?
There was a problem hiding this comment.
We agreed to add this in our sync yesterday; do you think it's unnecessary?
There was a problem hiding this comment.
We agreed to add this in our sync yesterday; do you think it's unnecessary?
I thought just one them solves our problems?
| // +unionMember | ||
| // +optional | ||
| // <opcon:experimental> | ||
| Condition ConditionProbe `json:"condition,omitempty,omitzero"` |
There was a problem hiding this comment.
Should we not call it ConditionEqual actually?
| // +kubebuilder:validation:XValidation:rule="self.matches('^[a-zA-Z0-9]+(?:\\\\.[a-zA-Z0-9]+)*$')",message="must contain a valid field path. valid fields contain upper or lower-case alphanumeric characters separated by the \".\" character." | ||
| // +required | ||
| // <opcon:experimental> | ||
| FieldA string `json:"fieldA,omitempty,omitzero"` |
There was a problem hiding this comment.
could we call it firstField (or leftField) ?
There was a problem hiding this comment.
I'm happy with fieldA==fieldB personally, do you feel strongly that it should be different?
I like that they get written symmetrically this way, but that's getting kind of nit-picky 🤷 i.e.
fieldA: foo
fieldB: bar
| // | ||
| // +kubebuilder:validation:MinLength=1 | ||
| // +kubebuilder:validation:MaxLength=200 | ||
| // +kubebuilder:validation:XValidation:rule="self.matches('^[a-zA-Z0-9]+(?:\\\\.[a-zA-Z0-9]+)*$')",message="must contain a valid field path. valid fields contain upper or lower-case alphanumeric characters separated by the \".\" character." |
There was a problem hiding this comment.
do we support also locating fields in an array? do we support json paths?
There was a problem hiding this comment.
The boxcutter probes are pretty primitive and don't support that at the moment, so I've excluded [] in the regex.
Provides an API which allows custom probe definitions to determine readiness of the CER phases. Objects can be selected for in one of two ways: by GroupKind, or by Label (matchLabels and matchExpressions). They can then be tested via any of: Condition, FieldsEqual, and FieldValue. Condition checks that the object has a condition matching the type and status provided. FieldsEqual uses two provided field paths and checks for equality. FieldValue uses a provided field path and checks that the value is equal to the provided expected value. Signed-off-by: Daniel Franz <dfranz@redhat.com>
e30eea0 to
79e203f
Compare
|
/override api-diff-lint |
|
@camilamacedo86: /override requires failed status contexts, check run or a prowjob name to operate on.
Only the following failed contexts/checkruns were expected:
If you are trying to override a checkrun that has a space in it, you must put a double quote on the context. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
/override api-diff-lint/api-diff-lint |
|
@camilamacedo86: /override requires failed status contexts, check run or a prowjob name to operate on.
Only the following failed contexts/checkruns were expected:
If you are trying to override a checkrun that has a space in it, you must put a double quote on the context. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
/override codecov/patch |
|
@camilamacedo86: Overrode contexts on behalf of camilamacedo86: codecov/patch DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
/override lint-api-diff |
|
@camilamacedo86: Overrode contexts on behalf of camilamacedo86: lint-api-diff DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
Hi @dtfranz We have the checks overrides. But we need LGTM from @pedjak and @perdasilva in this one. |
| // +kubebuilder:validation:MinProperties=1 | ||
| // +kubebuilder:validation:MaxProperties=1 |
There was a problem hiding this comment.
These don't appear to have made it to the generated CRD schema?
| // +optional | ||
| // +unionMember | ||
| // <opcon:experimental> | ||
| Label metav1.LabelSelector `json:"label,omitempty,omitzero"` |
There was a problem hiding this comment.
It's pretty standard to leverage label selector in this way, I suspect we will be ok leverage the metav1 types in this spec
Description
Provides an API which allows custom probe definitions to determine readiness of objects in the CER phases. Objects can be selected for in one of two ways: by GroupKind, or by Label (matchLabels and matchExpressions). They can then be tested via any of the following:
Also modifies the existing Namespace and PersistentVolumeClaim probes to use the new FieldValue probe.
Reviewer Checklist