-
Notifications
You must be signed in to change notification settings - Fork 7.8k
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
Add DNS capture into CNI. #32416
Add DNS capture into CNI. #32416
Conversation
Skipping CI for Draft Pull Request. |
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.
Looks great
@howardjohn Do you think if it is ok to make istio cni enablement a test framework flag? Local DNS cache test fails with CNI which we know won't work: https://prow.istio.io/view/gs/istio-prow/pr-logs/pull/istio_istio/32416/integ-pilot-k8s-tests_istio/1387096174833438720. We should just skip those cases when CNI is enabled, but that information is tricky to get without istio.enable_cni being a test framework flag. |
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.
Its a more general problem really. We are starting to treat our tests more and more like "conformance tests" where we bring some environment and then run a bunch of tests against it. So we have things like RequireIstioVersion, RequireClusterVersion, --istio.test.revision, --istio.test.skipVM, etc. We are also making tests workload agnostic which is pretty similar
We probably want a more general solution long term where a test can declare its dependencies and a test-runner can declare how its setup.
Short term a flag is probably fine, or in the job that runs CNI just add --istio.test.skip
?
@stevenctl for more opinions
I think a flag is fine; maybe we need some general flag like If we do add |
Ok, thanks for the feedback. I will add a flag for now then.
I think we should just control all CNI related stuff with this flag if we have it. Long term, when we have a feature skipping flag, we can go back and use operator install options. I created an issue to track this: #32493 |
/test all |
@howardjohn @stevenctl ptal thanks! |
Hello, I am waiting on this fix to be used in our product deployment. Please indicate which release version would this be available? I see istio 1.10 is released. So just wanted to get an idea. |
Same here; we are waiting to implement the new SmartDNS feature until this is released; currently on 1.8.6 |
Unfortunately this did not meet 1.10 cut. Will be in 1.11. |
Quick question - any chance we can either run a pre-release in our dev clusters to try it out, or you can shed some light on when 1.11 is scheduled for release? |
https://github.com/istio/istio/wiki/Dev%20Builds describes accessing dev
builds
…On Tue, Jun 15, 2021 at 2:08 PM Matt W ***@***.***> wrote:
Unfortunately this did not meet 1.10 cut. Will be in 1.11.
Quick question - any chance we can either run a pre-release in our dev
clusters to try it out, or you can shed some light on when 1.11 is
scheduled for release?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#32416 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEYGXLTWOSL2STHE7TVN5TTS66M3ANCNFSM43N45OUA>
.
|
@howardjohn thanks i can confirm that on the 1.11-dev release, the istio-cni is properly setting up the DNS iptables rules.. thanks!! |
@howardjohn @bianpengyuan Can we also backport this to 1.10 too? |
* Add DNS capture into CNI. * fix. * update * fix * capture all * fix. * Add a flag for CNI enablement in integration test. * remove cni test args.
fix #29511