Skip to content
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

OperatorPolicy Templates #235

Conversation

JustinKuli
Copy link
Member

@JustinKuli JustinKuli commented Apr 26, 2024

Adds the ability to use templates in Subscription and OperatorGroup fields in an OperatorPolicy. The template resolver uses the DynamicWatcher already used by the controller, so no additional plumbing was needed for new watches or in order to share a cache.

Also removes the special handling of hub-template errors from ConfigurationPolicy - that is now handled by the framework-addon (open-cluster-management-io/governance-policy-framework-addon#136), and so that logic didn't need to be added to the OperatorPolicy controller.

For https://issues.redhat.com/browse/ACM-10858

sub, subErr := buildSubscription(policy, r.DefaultNamespace)
disableTemplates := false

if disableAnnotation, ok := policy.GetAnnotations()["policy.open-cluster-management.io/disable-templates"]; ok {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like that this is an annotation instead of a spec field but I guess consistency with configuration policy is probably better than changing this at this point.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed 😆

@mprahl
Copy link
Member

mprahl commented Apr 29, 2024

/hold

@JustinKuli this looks great but let's block on this based on this PR sharing the dynamic watcher cache:
stolostron/go-template-utils#113

@@ -461,44 +461,6 @@ var _ = Describe("Test templatization", Ordered, func() {
return configmap
}, defaultTimeoutSeconds, 1).ShouldNot(BeNil())

By("Patch with invalid hub template")
Copy link
Contributor

@yiraeChristineKim yiraeChristineKim Apr 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this removed?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is now handled in the governance-policy-framework:
open-cluster-management-io/governance-policy-framework-addon#136

@yiraeChristineKim
Copy link
Contributor

/hold for Matt

@JustinKuli
Copy link
Member Author

/hold for some updates to template-utils, then I will bump the version this uses to get the DeepCopy improvements (and remove some manual DeepCopy calls we were doing here)

mprahl
mprahl previously approved these changes Apr 30, 2024
@mprahl
Copy link
Member

mprahl commented Apr 30, 2024

/unhold

The framework-addon now handles emitting compliance events for those
errors for all template policy types.

Refs:
 - https://issues.redhat.com/browse/ACM-10858

Signed-off-by: Justin Kulikauskas <jkulikau@redhat.com>
The Subscription and OperatorGroup fields can now utilize templates. The
resolver uses the DynamicWatcher already used by the controller, so no
additional plumbing was needed for new watches or in order to share a
cache.

Refs:
 - https://issues.redhat.com/browse/ACM-10858

Signed-off-by: Justin Kulikauskas <jkulikau@redhat.com>
The library now does the DeepCopy for us, to prevent accidental
mutations to objects in the cache.

Signed-off-by: Justin Kulikauskas <jkulikau@redhat.com>
mprahl
mprahl previously approved these changes May 1, 2024
@JustinKuli
Copy link
Member Author

I seriously feel like someone is playing a prank on me 😭

I half understand the "ConstraintsNotSatisfiable" failures now - the catalog was not responding (maybe because the previous test broke it on purpose), but I have no clue why it was suddenly happening very frequently... I'd believe that the quay operator version might have inconsistently removed the deprecated quayecosystems CRD, but it's still surprising that we only recently noticed it some of the time... and now the previous run had a disappearing CRD (or maybe the OLM label was removed?)...

Cursed, I tell you.

@JustinKuli JustinKuli force-pushed the 10858-oppol-templates branch 2 times, most recently from 6055b85 to 30923ea Compare May 1, 2024 18:15
mprahl
mprahl previously approved these changes May 1, 2024
@openshift-ci openshift-ci bot added the lgtm label May 1, 2024
From some test runs, it seems like some of the 3.8.x releases do not
always have the quayecosystems CRD, which makes the tests inconsistent.
From what I can tell, *none* of the 3.10.x releases will have that CRD,
so it should be consistent.

Signed-off-by: Justin Kulikauskas <jkulikau@redhat.com>
This test started failing relatively often. Debugging revealed that the
Subscription was getting into a ResolutionFailed=True condition, but
that it did not have the expected ConstraintsNotSatisfiable reason; it
looked like it was failing to resolve because the connection was refused
to the catalog.

Refs:
 - https://issues.redhat.com/browse/ACM-11414

Signed-off-by: Justin Kulikauskas <jkulikau@redhat.com>
The full policy status is often helpful when understanding what might be
unexpectedly happening in some of the operatorpolicy tests.

Signed-off-by: Justin Kulikauskas <jkulikau@redhat.com>
Copy link

openshift-ci bot commented May 1, 2024

New changes are detected. LGTM label has been removed.

Copy link

openshift-ci bot commented May 1, 2024

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: JustinKuli

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

1 similar comment
Copy link

openshift-ci bot commented May 1, 2024

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: JustinKuli

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

This should help with some consistency.

Signed-off-by: Justin Kulikauskas <jkulikau@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants