-
-
Notifications
You must be signed in to change notification settings - Fork 37
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
Allow for multiple service accounts to have ImagePullSecrets applied #6
Allow for multiple service accounts to have ImagePullSecrets applied #6
Conversation
Hi David, Thank you for your interest in the project. The contribution process is something that everyone needs to follow. I can see you've filled out part of the PR template, so that's something. The testing is also appreciated.
When you just put "no, but I wanted to" it doesn't create a good first impression, but I want to give you benefit of the doubt. So please can you raise an issue and start a discussion about why this is needed. Alex |
Hi Alex, The use case for this, was that I have multiple namespaces and deployments all using their own ServiceAccounts, while the original controller works with a many pull policies to one service account, my contribution allows for a Many:Many relationship of ImagePullPolicies to many ServiceAccounts. A better example would be that a helmchart in which requires no ability to customise the ServiceAccount in which is used (enforced new SA) - I'm unable to pull images from a private repository. With the patch/contribution applied, I'm able to patch said SA with the annotation |
@davidcollom how similar is your change to the following in #4? |
return nil | ||
} | ||
|
||
r.Log.Info(fmt.Sprintf("Getting SA for: %v", namespaceName)) | ||
r.Log.Info(fmt.Sprintf("Getting ServiceAccount: %v", namespacedName.Namespace)) |
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.
Wouldn't this print the wrong info? "Getting ServiceAccount NAMESPACE"
I'm uncomfortable with the additional number of lines added to secret_reconciler.go, it makes it very difficult to review and follow what is going on. Can you consider breaking some of that out into utility methods, and to remove nested expressions wherever you can? i.e. if you have an if/else and can return from the first condition, then do so and let the else be unindented as an expression. |
Signed-off-by: David Collom <david@collom.co.uk>
4a8d1be
to
458a8e9
Compare
Thank you for your contribution. I've just checked and your commit doesn't appear to be signed-off. That's something we need before your Pull Request can be merged. Please see our contributing guide. |
Signed-off-by: David Collom <david.collom@jetstack.io>
458a8e9
to
452438b
Compare
Let's start over with a new PR that makes fewer, smaller changes. |
Sorry for the lack of updates, I've been working on a new PR to fix this issue. I hope to get something ready for review this week, early next. |
We should have this covered now by the work @developer-guy has been doing. We still need something to clean up image pull secret lists after secrets have been removed. |
Description
Allow for
ImagePullSecrets
to be applied to other Service Accounts than the default.Which issue # does this fix? And was it approved before you worked on it?
No Issue, however a feature I felt worth while.
Fixes: #7
How Has This Been Tested?
Multiple times on my own cluster.
Scenarios Tried:
How are existing users impacted? What migration steps/scripts do we need?
No change, the default logic of the
default
SA is still valid.Only when users add the
alexellis.io/registry-creds.include
annotation to their ServiceAccounts will the ImagePullSecret be added.Checklist:
I have:
git commit -s