Conditional Data Gathering for Insights Operator #837
Conversation
Separated from the rest of the CVO stuff, because the insights folks might want to use this too [1]. [1]: openshift/enhancements#837
Separated from the rest of the CVO stuff, because the insights folks might want to use this too [1]. [1]: openshift/enhancements#837
Separated from the rest of the CVO stuff, because the insights folks might want to use this too [1]. [1]: openshift/enhancements#837
Separated from the rest of the CVO stuff, because the insights folks might want to use this too [1]. [1]: openshift/enhancements#837
Separated from the rest of the CVO stuff, because the insights folks might want to use this too [1]. [1]: openshift/enhancements#837
Separated from the rest of the CVO stuff, because the insights folks might want to use this too [1]. [1]: openshift/enhancements#837
Separated from the rest of the CVO stuff, because the insights folks might want to use this too [1]. [1]: openshift/enhancements#837
Separated from the rest of the CVO stuff, because the insights folks might want to use this too [1]. [1]: openshift/enhancements#837
|
There's one last discussion opened and it seems leaning toward current wording with "conditions" word. |
Serhii1011010
force-pushed
the
conditional-data-gathering
branch
from
371109a to
310df60
Compare
| In case GitHub is not available, we won't be able to add new rules, but the old ones would still be returned by | ||
| the service. | ||
|
|
||
| ## Design Details |
There was a problem hiding this comment.
I am missing here few words about the authentication. I guess the Insights operator will have to authenticate (using the "cloud.openshift.com" token from the pull-secret) to the new service.
I think it would be also good to describe the communication between the operator and the service more. How often will we query the service? What will the service API return - will be there some metadata e.g version or some time of update of the conditions? I remember there were some discussions about caching so this would be good to mention as well IMO.
There was a problem hiding this comment.
Added some info about implementation. Do you think we need the authentication? The rules aren't secret after all
There was a problem hiding this comment.
I am not sure, I guess everything running in crc requires authentication. We can check with @tisnik.
There was a problem hiding this comment.
@tremes Officially it would be needed. This is two-way thing as it allows the cluster (operator) to trust with whom it communicates (so not only for us to trust the cluster)
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: tremes 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 |
openshift-ci
bot
added
the
approved
|
@Sergey1011010: all tests passed! Full PR test history. Your PR dashboard. 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/test-infra repository. I understand the commands that are listed here. |
|
/lgtm |
No description provided.