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

Fix compliance when created resource has a status #161

Conversation

JustinKuli
Copy link
Member

Previously, the template would always be marked as compliant after the resource it defines was created. But if the object definition included a status, then the object might not actually match what was desired. Now, in this case, the template will be marked as non-compliant.

Refs:

@JustinKuli
Copy link
Member Author

I can squash the refactor commits together if that would be better.

Copy link
Member

@dhaiducek dhaiducek left a comment

Choose a reason for hiding this comment

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

Overall looks good, and thanks for the refactor work! The renamed variables at least will make it clearer to read/follow!

Comment on lines 1706 to 1693
hasStatus := false
if tmplObj, err := unmarshalFromJSON(objectT.ObjectDefinition.Raw); err == nil {
_, hasStatus = tmplObj.Object["status"]
}

if completed && hasStatus {
msg += ", but has a status that might not be correct yet"
reason += ", but has a status that might not be correct yet"
result.events = append(result.events, objectTmplEvalEvent{false, reason, msg})
} else {
result.events = append(result.events, objectTmplEvalEvent{completed, reason, msg})
}
Copy link
Member

@dhaiducek dhaiducek Aug 31, 2023

Choose a reason for hiding this comment

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

This is the creation flow, right? Does it still stay NonCompliant if a NonCompliant policy is updated and the status doesn't match or does some logic need to be there also?

Copy link
Member Author

Choose a reason for hiding this comment

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

Good catch, somehow I didn't think about the update flow having this same potential issue!

Copy link
Member Author

Choose a reason for hiding this comment

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

It looks like it might work correctly, but I'll adjust the test to be sure.

Copy link
Member Author

Choose a reason for hiding this comment

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

Copy link
Member Author

Choose a reason for hiding this comment

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

Initially, the CI here failed, but from the logs it looked like that was because the config-policy-controller was a little overwhelmed with the parallel tests. Because this test uses the status of another configurationpolicy, it can take extra loops to do what is expected... so bumping the timeouts to the default (1 minute) fixed it.

@JustinKuli JustinKuli force-pushed the 7020-enforced-w-status-compliance branch 2 times, most recently from 3421b23 to d9736b5 Compare August 31, 2023 19:02
@mprahl mprahl self-requested a review September 6, 2023 17:42
}

if completed && hasStatus {
msg += ", but has a status that might not be correct yet"
Copy link
Member

Choose a reason for hiding this comment

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

How about this?

Suggested change
msg += ", but has a status that might not be correct yet"
msg += ". The status will be validated on the next evaluation."

Copy link
Member

Choose a reason for hiding this comment

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

Instead, perhaps msg += ". The status will be verified on the next evaluation."

Copy link
Member Author

Choose a reason for hiding this comment

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

Good suggestion! I've reworded it slightly again, and I wanted to keep the comma: if a policy has multiple objects, the messages will be combined with semicolons, so using a period in the middle of a message seemed like it could be weird.

I also adjusted the reason to be shorter now.

metadata:
name: default
status:
lastEvaluatedGeneration: 3
Copy link
Member

Choose a reason for hiding this comment

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

Trippy....

Copy link
Member

Choose a reason for hiding this comment

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

Haha--I thought the same thing! I had to give it a double-take.

Copy link
Member Author

Choose a reason for hiding this comment

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

I like config policies, so I put a config policy in my config policy, so I can test config policies with config policies.

Copy link
Member

@mprahl mprahl left a comment

Choose a reason for hiding this comment

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

This looks good! The only thing is to consider changing the noncompliant message.

@@ -0,0 +1,78 @@
// Copyright (c) 2023 Red Hat, Inc.
// Copyright Contributors to the Open Cluster Management project
Copy link
Contributor

Choose a reason for hiding this comment

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

the file name what does "w" mean?

Copy link
Member Author

Choose a reason for hiding this comment

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

"with" - as in "enforce with status"

Previously, the template would always be marked as compliant after the
resource it defines was created. But if the object definition included
a `status`, then the object might not actually match what was desired.
Now, in this case, the template will be marked as non-compliant.

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

Signed-off-by: Justin Kulikauskas <jkulikau@redhat.com>
The `object` and `unstruct` fields were not self-explanatory. Now they
are `existingObj` and `desiredObj` respectively. This will help readers
understand why they are used the way they are.

Signed-off-by: Justin Kulikauskas <jkulikau@redhat.com>
In both instances, the object is already assured to be non-nil, so there
are no errors that can occur here.

Signed-off-by: Justin Kulikauskas <jkulikau@redhat.com>
By keeping track of which branch we're in, it became obvious that the
`generateSingleObjReason` calls were actually just static lookups. So
that function has been removed.

Signed-off-by: Justin Kulikauskas <jkulikau@redhat.com>
Putting this in the function itself means that the function could be
called from multiple places, and the metrics would still be recorded.

Signed-off-by: Justin Kulikauskas <jkulikau@redhat.com>
@JustinKuli JustinKuli force-pushed the 7020-enforced-w-status-compliance branch from d9736b5 to 02cf4b5 Compare September 7, 2023 14:34
@openshift-ci
Copy link

openshift-ci bot commented Sep 7, 2023

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: JustinKuli, mprahl, yiraeChristineKim

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:
  • OWNERS [JustinKuli,mprahl,yiraeChristineKim]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-merge-robot openshift-merge-robot merged commit 406ccf7 into open-cluster-management-io:main Sep 7, 2023
4 checks passed
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.

5 participants