istio.io
istio.io copied to clipboard
istio
Remove global.externalIstiod from remote examples
Description
The need to use this value was removed in https://github.com/istio/istio/pull/53542.
Reviewers
- [ ] Ambient
- [ ] Docs
- [x] Installation
- [ ] Networking
- [ ] Performance and Scalability
- [ ] Extensions and Telemetry
- [ ] Security
- [ ] Test and Release
- [ ] User Experience
- [ ] Developer Infrastructure
- [ ] Localization/Translation
Hi @luksa. 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-sigs/prow repository.
Ah, the tests didn't run against the latest Istio version, hence the failure. Is there automation that updates the Istio version in this repo or do I need to update it myself?
Ah, the tests didn't run against the latest Istio version, hence the failure. Is there automation that updates the Istio version in this repo or do I need to update it myself?
There is some automation, runs daily at 2am UTC.
Looks like there were changes in istio/istio that broke doc tests again... I don't have cycles at the moment to look in to it, but if another docs maintainer cannot I'll try when I can.
Looks like there were changes in istio/istio that broke doc tests again... I don't have cycles at the moment to look in to it, but if another docs maintainer cannot I'll try when I can.
I suspect https://github.com/istio/istio/pull/53542 probably broke an assumption in the doc tests in this repo (I kinda figured that would be the case, multicluster is only tested by these two different suites - the one here and the one in the main repo - and they do not fully agree/have coherence with each other).
That assumption is probably bad, and the docs tests should be updated/fixed.
It looks like the injected sidecars in the doctests are failing to come up because the webhook name is wrong (somehow, despite https://github.com/istio/istio/pull/53542, something is expecting a Service named istiod-remote and it's getting istiod, or vice-versa), so injection is failing.
@bleggett you sure this is running against the Istio version that includes the changes in istio/istio#5? According to the logs, the test ran against ISTIO_VERSION=1.24-alpha.1c546ae8a14a9a64f171c7fe228925ebaf3a3348, which is a week old commit, whereas my changes went in yesterday.
@bleggett you sure this is running against the Istio version that includes the changes in istio/istio#5? According to the logs, the test ran against
ISTIO_VERSION=1.24-alpha.1c546ae8a14a9a64f171c7fe228925ebaf3a3348, which is a week old commit, whereas my changes went in yesterday.
Oh yep, that would be why.
Feel free to manually update the ref in this PR, with go get: https://github.com/istio/istio.io/blob/master/README.md#updating-the-test-reference-for-a-given-release-stream
@bleggett you sure this is running against the Istio version that includes the changes in istio/istio#5? According to the logs, the test ran against
ISTIO_VERSION=1.24-alpha.1c546ae8a14a9a64f171c7fe228925ebaf3a3348, which is a week old commit, whereas my changes went in yesterday.Oh yep, that would be why.
Feel free to manually update the ref in this PR, with
go get: https://github.com/istio/istio.io/blob/master/README.md#updating-the-test-reference-for-a-given-release-stream
That should only happen in the automated PRs.. do not do it in regular docs PRs.. especially if there is something that could be broken.
/hold
I'll remove the go.mod updates as soon the automator updates to the Istio version required by this change.
That should only happen in the automated PRs.. do not do it in regular docs PRs.. especially if there is something that could be broken.
(for my own understanding) - what is the extra risk here? The automator opens a PR that must pass the same CI gates as any other PR, so whether the ref is bumped in a person PR versus an automator PR shouldn't change stability much - the same CI has to pass either way, or the merge won't happen.