-
Notifications
You must be signed in to change notification settings - Fork 8k
add imagePullSecrets to sidecar injection template #24365
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
Conversation
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.
Have you tested this case? What if the original pod already has imagePullSecrets
?
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.
won't you need to add this secret to every namespace?
We should at least add a test under inject_test.go for this if we are going to add this.
In this case, it should append to the list of imagePullSecrets. I thought the code already does that? |
I think this is OK to assume. If any istio participating workload needs to pull down the istio-proxy image, the pullSecrets will have to be made available in all namespaces |
If you add a test then we won't have to guess 🙂 |
All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the ℹ️ Googlers: Go here for more info. |
add imagePullSecrets to sidecar injection template
fa559bb
to
ab2aa4d
Compare
CLAs look good, thanks! ℹ️ Googlers: Go here for more info. |
@@ -761,6 +761,8 @@ func IntoObject(sidecarTemplate string, valuesConfig string, revision string, me | |||
|
|||
podSpec.DNSConfig = spec.DNSConfig | |||
|
|||
podSpec.ImagePullSecrets = append(podSpec.ImagePullSecrets, spec.ImagePullSecrets...) |
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.
Thanks to the unit tests, I added this bugfix :).
Good call @howardjohn !
Thanks for the approve @howardjohn . Do you agree this needs to be cherrypicked to release-1.6? |
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. At some point, @istio/wg-environments-maintainers needs to have a discussion and agreement about "one API" to rule hem all. Currently we have three, and this PR adds to the deprecated API global.yaml
. I understand completely why this option is necessary, although at some point, we need to consider a reorg of all of the 3 APIs (values,yaml, IsitoOperator, and MeshConfig) into one API.
The current (fuzzy) agreement as I understand it is to push everything to MeshConfig
. I am not convinced this is a good choice as MeshConfig
is already poorly organized.
What I'd like to see is one new object, that every component understands, that meets the criteria for a stable API. This viewpoint means deprecating MeshConfig
in favor of IstioConfig
- which would be a new take on IstioOperator - but with all of the stuff in MeshConfig
.
For now, we can make an exception and add to values.yaml - but again, the WG needs to have further discussion and a concrete agreement on one API - used throughout istiod (mostly PIlot), as well as istioctl and the standalone operator and the helm charts.
Cheers,
-steve
cc / @rcernich I know you may be doing some work in this area. Also @ostromart is looking into this deeply. I can bring us together - but would need an initial proposal. |
|
@tariq1890 I've selected this PR for backport to 1.6. Cheers, |
In response to a cherrypick label: #24365 failed to apply on top of branch "release-1.6":
|
In response to a cherrypick label: new issue created for failed cherrypick: #24437 |
(cherry picked from commit 2e3459b)
Thanks @sdake @howardjohn |
@sdake, I'm working on a POC that reorganizes the settings in values.yaml based on feature/area of concern. I've also drafted an RFC, which should be ready for review next week. |
add imagePullSecrets to sidecar injection template
Since
imagePullSecrets
is a part of theSidecarInjectionSpec
, it would be good to illustrate the usage of this through the manifest charts. Moreover, global values are used as settings in the sidecar injection template, so it only makes sense that we use the same pattern for providing theimagePullSecrets
via.Values.global
[X] Configuration Infrastructure
[ ] Docs
[X] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[X] User Experience
[ ] Developer Infrastructure