-
Notifications
You must be signed in to change notification settings - Fork 36
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
Resource selector for ConfigurationPolicy
#129
Resource selector for ConfigurationPolicy
#129
Conversation
|
||
### Goals | ||
|
||
- Add a `resourceSelector` to `ConfigurationPolicy` to allow the controller to handle objects |
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.
Do you think another goal is to consolidate the compliance message for an object-template with a resource selector? One of the main drawbacks with object-templates-raw is you get a separate compliance message per object-template. The use of a namespaceSelector currently consolidates the compliance message but that is limited as you mention in the introduction.
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.
That's a good point--the message could probably be refactored to list out the objects per namespace rather than have a message for every object--is that what you mean?
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.
Either that or consolidate to something like Pods found as specified: namespace1/name1, namespace2/name2; Pods updated: namespace1/name3
per object-template with a resource selector.
4a99b26
to
5aa3e94
Compare
- Consolidate compliance messages to list out objects per namespace (one downside to the alternative | ||
`object-templates-raw` is there's a compliance message for each object) |
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.
This brings up the question: is the content in the compliance message part of our API which we should be very careful about changing? I suppose we could only change the compliance messages to a new form if the policy uses a resourceSelector
, but that seems potentially confusing to users.
Personally, I don't think we need to preserve the existing messages exactly, as long as similar content is still present by default. We could consider exposing a "legacy" message into the CustomMessage template for use, in case a user has some other tooling built on the current format.
5aa3e94
to
c0ec93f
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.
/hold for others
ref: https://issues.redhat.com/browse/ACM-14828 Signed-off-by: Dale Haiducek <[email protected]>
c0ec93f
to
f1910f3
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.
/unhold
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dhaiducek, 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:
Approvers can indicate their approval by writing |
964321d
into
open-cluster-management-io:main
ref: https://issues.redhat.com/browse/ACM-14828
Closes #128