Skip to content
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

Conversation

robertpanzer
Copy link
Contributor

@robertpanzer robertpanzer commented Mar 29, 2019

…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.

@googlebot
Copy link
Collaborator

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.
In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

@googlebot googlebot added the cla: no Set by the Google CLA bot to indicate the author of a PR has not signed the Google CLA. label Mar 29, 2019
@istio-testing
Copy link
Collaborator

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: robertpanzer
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: kyessenov

If they are not already assigned, you can assign the PR to them by writing /assign @kyessenov in a comment when ready.

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@istio-testing
Copy link
Collaborator

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 /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

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.

@robertpanzer robertpanzer force-pushed the fix-12873-sidecar-outbound-traffic-policy branch from f146f74 to 22c670f Compare March 29, 2019 14:18
@googlebot
Copy link
Collaborator

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

@googlebot googlebot added cla: yes Set by the Google CLA bot to indicate the author of a PR has signed the Google CLA. and removed cla: no Set by the Google CLA bot to indicate the author of a PR has not signed the Google CLA. labels Mar 29, 2019
@mandarjog
Copy link
Contributor

/ok-to-test

@istio-testing istio-testing added ok-to-test Set this label allow normal testing to take place for a PR not submitted by an Istio org member. and removed needs-ok-to-test labels Mar 29, 2019
@ozevren ozevren requested review from costinm and andraxylia and removed request for ozevren March 29, 2019 18:08
ALLOW_ANY = 1;

reserved 2;
reserved "VIRTUAL_SERVICE_ONLY";
Copy link
Member

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

Copy link
Contributor Author

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?

Copy link
Member

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..

Copy link
Contributor Author

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.

Copy link
Contributor Author

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).

@robertpanzer robertpanzer force-pushed the fix-12873-sidecar-outbound-traffic-policy branch from 22c670f to c877e20 Compare April 2, 2019 07:47
…verride outbound traffic policy per sidecar
@robertpanzer robertpanzer force-pushed the fix-12873-sidecar-outbound-traffic-policy branch from c877e20 to 4b363cd Compare April 2, 2019 07:56
Copy link
Member

@rshriram rshriram left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cc @louiscryan thoughts?

@rshriram rshriram merged commit cf912ce into istio:release-1.1 Apr 5, 2019
@costinm
Copy link
Contributor

costinm commented Apr 5, 2019

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.

@costinm
Copy link
Contributor

costinm commented Apr 5, 2019

@duderino

@costinm
Copy link
Contributor

costinm commented Apr 5, 2019

On the content of the API change: I don't think this is the best way, it has multiple problems:

  • like public/private, it is too narrow
  • not aligned with 'egress' and 'exportTo' - where for internal traffic we provide a list
  • not aligned with ServiceEntry - which is normally used to control egress, and has different syntax

It is also quite confusing - what is 'outbound traffic' ?

  • Egress is used in most places in the docs. What is different between egress and outbound traffic and why a new term used here ?
  • traffic to other Istio services is also outbond traffic. Is it affected ? Why ? Why not ?
  • what happens when we want to allow specific ports, or http hosts ?

@robertpanzer
Copy link
Contributor Author

Sorry for creating this.
OutboundTrafficPolicy is already part of Istio's Mesh configuration and I agree that it is confusing.
But all that configuration does is to allow application owners to refine this configuration for their workloads.

I think though that the term "external" refers to MESH_EXTERNAL.

@robertpanzer robertpanzer deleted the fix-12873-sidecar-outbound-traffic-policy branch April 5, 2019 16:51
duderino pushed a commit that referenced this pull request Apr 5, 2019
…icy to override outbound traffic policy per sidecar (#887)" (#894)

API changes to released Istio versions should go through TOC review first, before being submitted.

This reverts commit cf912ce.
@robertpanzer robertpanzer restored the fix-12873-sidecar-outbound-traffic-policy branch July 2, 2019 14:39
nacx pushed a commit to nacx/api that referenced this pull request Apr 15, 2020
* 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla: yes Set by the Google CLA bot to indicate the author of a PR has signed the Google CLA. ok-to-test Set this label allow normal testing to take place for a PR not submitted by an Istio org member.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants