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
Tie SCC lifecycle with KataConfig #193
Conversation
/assign @gkurz |
@bpradipt: GitHub didn't allow me to assign the following users: gkurz. Note that only openshift members, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. In 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/test-infra repository. |
I'm skipping the test case commit as I don't really have the knowledge to review. Rest looks good. |
/retest |
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.
LGTM. Thanks @bpradipt !
The tests seems to be failing because of infra problems, not related to the changes in this PR. |
/retest |
4 similar comments
/retest |
/retest |
/retest |
/retest |
last try |
@bpradipt: The following test failed, say
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. |
Fixes: KATA-1569
- Description of the problem which is fixed/What is the use case
The custom SCC created by the operator doesn't get deleted on the removal of KataConfig
@gkurz attempted to fix the issue in the following PR #191.
However, triggered by the suggestion from @littlejawa, we felt its logical to align the SCC lifecycle with the KataConfig lifecycle in further discussions. There is no reason to keep the SCC handling separated since kata-monitor pods use the custom SCC, and kata-monitor pods get created only after KataConfig creation. Thanks to @littlejawa and @gkurz for forcing us to relook at the issue which resulted in this PR. With this PR, the SCC gets created on KataConfig creation and cleaned up on deletion of the KataConfig.
- What I did
Changed how SCC gets created and deleted
- How to verify it
Check whether the customer SCC gets deleted after KataConfig deletion
- Description for the changelog
Tie SCC lifecycle with KataConfig