-
Notifications
You must be signed in to change notification settings - Fork 547
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
Fixes istio/istio#12873. Add field Sidecar.OutboundTrafficPolicy to o… #887
Fixes istio/istio#12873. Add field Sidecar.OutboundTrafficPolicy to o… #887
Conversation
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. ℹ️ Googlers: Go here for more info. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: robertpanzer If they are not already assigned, you can assign the PR to them by writing The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Hi @robertpanzer. Thanks for your PR. I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
f146f74
to
22c670f
Compare
CLAs look good, thanks! ℹ️ Googlers: Go here for more info. |
/ok-to-test |
networking/v1alpha3/sidecar.proto
Outdated
ALLOW_ANY = 1; | ||
|
||
reserved 2; | ||
reserved "VIRTUAL_SERVICE_ONLY"; |
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.
you dont need these two here.. since you are copying the struct
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.
Awesome, thank you!
So you mean I can remove the struct from v1alpha1?
Or do you mean I can remove the reserved 2; and the following line?
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 dont think you can remove the struct from the mesh/v1alpha1 without causing some form of circular dependency thing IIRC.. though @ozevren would have to attest to that. For the purpose of this PR though, I would suggest that you remove the reserved 2 and the reserved VIRTUAL.. line as this is an entirely new message introduced in this file..
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, I'll do that. Thanks for the clarification.
My original intent was to have this struct only in networking.v1alpha3 and remove the one in mesh.v1alpha1.
There is already one dependency in that direction; adding a reference to mesh.v1alpha1.OutboundTrafficPolicy from networking.v1alpha3 would create a cyclic dependency.
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.
@rshriram I removed the reserved field and updated the PR by amending the commit (To avoid the breaking change in proto.lock in the commit history).
22c670f
to
c877e20
Compare
…verride outbound traffic policy per sidecar
c877e20
to
4b363cd
Compare
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.
cc @louiscryan thoughts?
Please revert and move to master - AFAIK we are not supposed to make API changes in 1.1 ( or it needs to go trough release manager, review, etc ) release-1.1 branch is released every week - so the TOC review can be too late. |
On the content of the API change: I don't think this is the best way, it has multiple problems:
It is also quite confusing - what is 'outbound traffic' ?
|
Sorry for creating this. I think though that the term "external" refers to MESH_EXTERNAL. |
* regenerate pb.go with 1.2.0 Signed-off-by: Lizan Zhou <lizan@tetrate.io> * go mod tidy Signed-off-by: Lizan Zhou <lizan@tetrate.io> * fix istio/api to 1.1.0-snapshot.5 Signed-off-by: Lizan Zhou <lizan@tetrate.io> * fix fmt Signed-off-by: Lizan Zhou <lizan@tetrate.io> Mirrored from https://github.com/tetrateio/tetrate @ de742a09f874e00c44445410478d458c260641ed
…verride outbound traffic policy per sidecar
This PR tries to solve https://github.com/istio/istio/12873.
For that it adds a field Sidecar.OutboundTrafficPolicy that is currently a copy of the same field in the Mesh configuration.
I actually wanted to reuse that type and move it to network/v1alpha3, but the build has another opinion on this and fails.
Would it work to move the type mesh/v1alpha1.MeshConfig_OutboundTrafficPolicy to network/v1alpha3/OutboundTrafficPolicy?
In my understanding this should result in the same Wire format, so that it should still work to run a newer Galley with an older Pilot or vice versa.
Are there any opinions on this?
And if it would be ok to move this, how can I do it? Currently make fails when moving this type.