Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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: service sccount to service account impersonation to support universe domain #1528
feat: service sccount to service account impersonation to support universe domain #1528
Changes from 16 commits
ea42036
55ccb61
600fd68
6b86b3a
2fbf761
8dfa6ef
09e80aa
a8bccd1
4b43ad8
bca6a42
a987ecd
995209d
4de0b9b
12ab22e
d334e46
ece8884
78d3a03
9631acd
61fd304
fc24a06
56acc23
fdb6582
00a8cf2
1313788
f3a6f23
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
I'm still not sure why this call is required for GDU but not required for nonGDU, is there any feature that is only supported in GDU?
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.
I am convinced that this is not needed for nonGDU, reasons in description above.
For GDU, I am not 100% convinced that this is required before initialize step. But out of precautious, I do not want to change the flow for GDU in this pr. I will raise a separate issue to investigate for GDU flow.
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.
to answer Blake's question - GDU has token endpoint, nonGDU does not :)
SSJ is a primary flow is GDU now as well. This should be a fallback scenario if SSJ is disabled, execute conditionally if SSJ flag is disabled.
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.
updated condition to also skip for GDU SSJ flow.
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.
I don't think we have to override this method as it is already public in the parent. I noticed that it seems we are overriding the builder methods in other subclasses of the builder, but I think that was a mistake.
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.
I debated this in my mind. One benefit I see overriding the setter allows for a fluent builder API where method calls can be chained without requiring explicit casting to ImpersonatedCredentials. In this case, I feel it provides a slightly better experience for users setting explicit UD
So user can do
instead of casting:
While generally it's best to avoid overriding public methods if possible, override setters in Builders is kind of a special case and more acceptable. .e.g. overriding Builder setters seems to be a pattern in other libraries like Guava (example)
One other concern is removing other overrides in other credential classes will be breaking change to customers code.
That said, I don't feel too strongly about this, and I believe exposing this setter is not a hard requirement for now. If you have any other concerns, I can remove this for now. What do you think?
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.
I don't think customers have to cast the credential to
ImpersonatedCredentials
tosetUniverseDomain()
, I verified in my local that it works. Can you please double check it?For the Guava example, yes they are doing it because there are some additional logics, but we are not doing anything special other than calling
super.setUniverseDomain()
. So I think we can delete it at this moment and add it later if needed.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.
Confirming that explicit overrides were added to avoid casting.
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.
Min and I confirmed that we do need explicit casting right now. However, the problem is that the parent builder's setters should return the child types. I created a demo PR for a potential fix. Also see how protobuf's GeneratedMessageV3 does it.
That being said, this should be separate problem to solve, so it's OK to override the parent's setters right now.