-
Notifications
You must be signed in to change notification settings - Fork 7.7k
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
Istioctl vs Operator vs Helm path forward #44814
Comments
I very much like the trajectory of this, I have been wanting to simplify the install experience for while.
Maybe this could be solved by using schema validation?
I think I prefer option 2.
Do we have any information on the user base?
This would be great IMO. But keeping the IstioOperator API around would mean maintaining the whole conversion logic.
This seems like an easy thing to do. Agreeing with a lot of points here. From my perspective, I think we should strive to make
|
1 on treating |
Istioctl install is using the same config as operator. Which is a kind of CRD that is not applied or reconciled. |
I would add that with all refactorings and with ambient behaving in different way leaves an unknown part of the install API in an undeterministic state. |
Not stale |
not stale |
related: #47838 |
I think there are still users of the Istio Operator as its been in the docs. The issue seems to discuss that the initial step will be to remove from the documents the existence of the Istio Operator. Then the next steps are to remove the operator image and the associated testing. I was wondering what the timeline will look like for when the depreciation will be completed. |
maybe we can move IstioOperator controller to istio-ecosystem org? |
Isn't this still implies to users that using this operator is a valid approach with Istio, which in fact is a poor practice? |
Using the istio-ecosystem does give users time to migrate away from the current Istio Operator. I think we need to be more clear what is the deprecation timeline and if there is a migration strategy. |
Also I think there was a plan to announce deprecation at KubeCon. Does that mean that the plan is to remove the Istio Operator from the docs after KubeCon? |
We have decided to not make an announcement on deprecation until we have finalized a migration strategy |
FYI we're working on https://github.com/istio-ecosystem/sail-operator now (initial commit to main branch coming soon), which will be a new operator maintained by us at Red Hat. that could potentially become a migration path for users of the legacy operator. we're sticking to the helm values API, so migration shouldn't be hard. in addition to what the legacy operator provided, sail-operator will support multiple istio versions and istio version upgrades, both automatic in-place upgrades and semi-automatic canary upgrades |
This is awesome! Please write an Istio blog post about it |
Our different installation methods have caused tension and confusion. This issue aims to discuss some issues we have seen and some ideas for fixing these.
In general, we don't want to remove any of these to reduce churn. Similarly, we don't want major changes to any of them, either.
Some ideas...
istioctl
. Pretend it does not exist for all intents and purposes, other than for docs. We can move docs into operator/ or some wiki or point to archives. Add warnings to all istioctl commands using it.installed-state
IstioOperator entirelya. Stop installing IstioOperator CRD when not using in-cluster operator
b. Fix commands depending on it to use alternative inputs (see (4))
istioctl install
a small shim overhelm install
a. May be less viable for the in-cluster operator, though.
kind: IstioOperator
into istioctl. Update all docs to not have it.The text was updated successfully, but these errors were encountered: