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

feat(collector): checking existing service account before create running pod #1222

Merged
merged 1 commit into from
Jun 15, 2023

Conversation

DexterYan
Copy link
Member

@DexterYan DexterYan commented Jun 14, 2023

Description, Motivation and Context

  • check the service account before creating the running pod
  • if the service account didn't exist, create the service account first

Related to PR: #1196 (comment)
Fixes: #1223

Checklist

  • New and existing tests pass locally with introduced changes.
  • Tests for the changes have been added (for bug fixes / features)
  • The commit message(s) are informative and highlight any breaking changes
  • Any documentation required has been added/updated. For changes to https://troubleshoot.sh/ create a PR here

Does this PR introduce a breaking change?

  • Yes
  • No

@DexterYan DexterYan requested a review from a team as a code owner June 14, 2023 02:56
@DexterYan DexterYan added type::bug Something isn't working bug::regression labels Jun 14, 2023
@xavpaice
Copy link
Member

I have one concern, in that we should already have the default serviceaccount there, and if we do not, do we really want to create it as part of a support-bundle run?

if err != nil {
klog.V(2).Infof("Failed to get service account %s, creating it", serviceAccountName)
// Service account doesn't exist, create it
_, err = client.CoreV1().ServiceAccounts(namespace).Create(context.Background(), &corev1.ServiceAccount{
Copy link
Member

Choose a reason for hiding this comment

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

this will help immensely in tests with k3s, but we want to be sure that it's the behavior we want with production sites - the end user might not expect us to be creating serviceAccount resources when running Troubleshoot, and everything else gets deleted at the end. I'd not want to go deleting the default sa in this case.

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 think this one only happens when user has specified its running service account and namespace in spec yaml, then we just check if the service account existed. otherwise just warning it.

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 have changed the logic that we just get if the service account existed or not. Not creating it

@DexterYan
Copy link
Member Author

I have one concern, in that we should already have the default serviceaccount there, and if we do not, do we really want to create it as part of a support-bundle run?

In most standard k8s cluster, we should have default service account in default namespace, however, as you pointed out, I think we should give a warning not fail or create the default service account in default namespace. If the user is intended to delete default account. We should not create it again.Otherwise, we need to cleanup.

@DexterYan DexterYan force-pushed the dx/add-service-account-check branch from ee3a00d to 92d495a Compare June 14, 2023 23:42
Copy link
Member

@xavpaice xavpaice left a comment

Choose a reason for hiding this comment

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

LGTM

@xavpaice xavpaice merged commit fefe118 into main Jun 15, 2023
21 checks passed
@xavpaice xavpaice deleted the dx/add-service-account-check branch June 15, 2023 03:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug::regression type::bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

preflight-e2e-test fail due to default service account missing in default namespace
2 participants