-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
core: Add Attributes.Key for authority in EquivalentAddressGroup (#4469) #6126
Conversation
|
* The authority to be used when constructing {@link io.grpc.Channel}s to this this EquivalentAddressGroup. | ||
*/ | ||
@EquivalentAddressGroup.Attr | ||
public static final Attributes.Key<String> ATTR_CHANNEL_AUTHORITY = |
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.
This should be a public API, not in internal. @zhangkun83, is the only place we have for things like this io.grpc.Grpc
?
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.
Yes, the last time I checked io.grpc.Grpc
is the only place where these Attrs are defined (and they all are prefixed TRANSPORT_ATTR_
) . I guess this can also be considered a TRANSPORT_ATTR_
?
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 would suggest we name it as ATTR_AUTHORITY_OVERRIDE
and put it in EquivalentAddressGroup
. TRANSPORT_ATTR_
is for pulling information out of transport, while this attribute is passing information to the transport, which is different. It's better to put the attributes close to where it's used. TRANSPORT_ATTR_
is in Grpc
because there is no other public place where we can put them, since transport API is internal.
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.
Makes sense. Agreed on all points.
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.
Renamed the attribute as suggested by @zhangkun83 . I am assuming that
put it in
EquivalentAddressGroup
means using the @EquivalentAddressGroup.Attr
annotation as I already did?
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.
No, I think he meant move the field to io.grpc.EquivalentAddressGroup
, directly.
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.
ok. done.
@@ -50,6 +50,13 @@ | |||
public static final Attributes.Key<Boolean> ATTR_LB_PROVIDED_BACKEND = | |||
Attributes.Key.create("io.grpc.grpclb.lbProvidedBackend"); | |||
|
|||
/** | |||
* The authority to be used when constructing {@link io.grpc.Channel}s to this this EquivalentAddressGroup. |
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.
this this -> this
Also did you mean to say Subchannel instead of Channel (which makes sense given the main PR comment.
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.
@sanjaypujare, I went for Channel as the Subchannel could not be referenced from this context. I changed this to Subchannel and removed the javadoc link.
*/ | ||
@EquivalentAddressGroup.Attr | ||
public static final Attributes.Key<String> ATTR_CHANNEL_AUTHORITY = | ||
Attributes.Key.create("io.grpc.grpclb.channelAuthority"); |
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.
Please rename the key string accordingly.
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.
@zhangkun83. Done, although I am not entirely sure about the convention here.
|
||
// Update reused subchannels with possibly updated EquivalentAddressGroups | ||
for (EquivalentAddressGroup addressGroup : unchangedAddrs) { | ||
subchannels.get(addressGroup).updateAddresses(resolvedAddresses.getAddresses()); |
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.
No, no. This updates each subchannel to point to all addresses. It should be closer to:
subchannels.get(addressGroup).updateAddresses(addressGroup);
UpdateAddresses changes the addresses that the subchannel connects to, while leaving any connection in-place if the addresses overlap. In this case, the addresses should be identical, however the attributes may have changed. So we're using it to just swap to the new attributes.
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.
Done
setsDifference(currentAddrs.keySet(), latestAddrs.keySet()); | ||
Set<EquivalentAddressGroup> unchangedAddrsStripped = | ||
setsDifference(currentAddrs.keySet(), removedAddrsStripped); | ||
Set<EquivalentAddressGroup> addedAddrs = |
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.
Part of the point of stripping the Attributes was to avoid equals/hashCode of Attributes. This is using equals/HashCode. You should use the stripped versions of the set in loops, and then use latestAddrs.get()
to pass the full-featured EAG to subchannel.
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 refactored this to get rid of the stripping entirely (as I suggested earlier).
For this to be possible I had to make the "setsDifference" method ungeneric. I personally think this makes the code a lot easier to read but please let me know what you think.
I also added a unit test to validate the new diffing.
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.
We're still having trouble getting on the same page with RR, so I've sent out a PR to fix it up. That should make this PR much simpler, since that was where most of the issues were coming from.
import io.grpc.Metadata; | ||
import io.grpc.Metadata.Key; | ||
import io.grpc.NameResolver; | ||
import io.grpc.Status; | ||
import io.grpc.internal.GrpcAttributes; | ||
import io.grpc.internal.ServiceConfigUtil; | ||
|
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.
Our style doesn't put blank lines between these imports.
Set<EquivalentAddressGroup> latestAddrs = stripAttrs(servers); | ||
Set<EquivalentAddressGroup> addedAddrs = setsDifference(latestAddrs, currentAddrs); | ||
Set<EquivalentAddressGroup> removedAddrs = setsDifference(currentAddrs, latestAddrs); | ||
Set<EquivalentAddressGroup> latestAddrs = new HashSet<>(servers); |
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.
This still uses the equals() from Attributes, because EAG uses the equals() from attributes. I'll go ahead and fix up RR in a separate PR (#6136).
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.
Ok, thanks for helping out. Should I squash my commits and discard the RR-related changes?
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.
Yes, please do.
Ideally there would also be a test. I think copying InternalSubchannelTest.eagAttribute_propagatesToTransport would work well. You'd change attr
to include ATTR_AUTHORITY_OVERRIDE and change the line with createClientTransportOptions()
to set the authority.
This enables NameResolvers to dynamically provide authority for each Subchannel
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 just realized the experimental API annotation was missing. Since this is really close now, creating the issue now seems good.
(Approving, since this is also something I could do behind you, after merging this PR.)
/** | ||
* The authority to be used when constructing Subchannels for this EquivalentAddressGroup. | ||
*/ | ||
@Attr |
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.
Add an @ExperimentalApi
annotation here. Create a new issue to stabilize the API, and include it as the value. You can look at other experimental apis to see the format.
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.
Done
…UTHORITY_OVERRIDE
@Attr | ||
@ExperimentalApi("https://github.com/grpc/grpc-java/issues/6138") | ||
public static final Attributes.Key<String> ATTR_AUTHORITY_OVERRIDE = | ||
Attributes.Key.create("io.grpc.grpclb.authorityOverride"); |
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 think this is not related to io.grpc.grpclb
. Maybe io.grpc.EquivalentAddressGroup.authorityOverride
is a better name.
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.
Done. I went ahead and made this change, since it was trivial.
@enguerrand, thank you! This did not make the branch cut (happened yesterday), which means it would be included in the release-after-next, in 2 months. How much of an issue would that be for you? |
@ejona86, glad to see the changes were merged. If would certainly have helped me to have the changes in the upcoming release but I understand that you have processes to follow... |
This enables NameResolvers to dynamically provide authority for each
Subchannel
Fixes #4469