I very much like the trajectory of this, I have been wanting to simplify the install experience for while.

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.

* Confusion between istioctl vs operator, mostly driven by the IstioOperator API
  
  * Users think it means "do not use istioctl"
  * Users try to kubectl apply it

* Confusion with installed-state - users think it is reconciled

* Feature parity gaps between helm and istioctl
  
  * Some commands use installed-state; helm doesn't handle this (but it does have its own replacement)
  * Less validation in helm

Maybe this could be solved by using schema validation?

* IstioOperator API drives users to monolithic installations, which are hard to maintainer after day0

* Docs inconsistently document one approach or the other.

* Wasted effort maintaining installation code, which is outside of our expertise

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

1. Rename "Istio Operator" in all docs to "Istio In-Cluster Operator"

I think I prefer option 2.

2. Remove documentation about "Istio Operator" entirely. Hide commands in `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.

Do we have any information on the user base?

3. Remove `installed-state` IstioOperator entirely
   a. Stop installing  IstioOperator CRD when not using in-cluster operator
   b. Fix commands depending on it to use alternative inputs (see (4))

4. Remove all install code, make `istioctl install` a small shim over `helm install`
   a. May be less viable for the in-cluster operator, though.

This would be great IMO. But keeping the IstioOperator API around would mean maintaining the whole conversion logic.

5. Allow inputs without `kind: IstioOperator` into istioctl. Update all docs to not have it.

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 helm the canonical install method and everything else should be done from that perspective. So I would suggest:

• make the helm values a proper API (ie tougher checks around new settings etc.)
• add schema validation to helm values
• make the helm values our default install configuration
  • it's a bit confusing IMO that the spec settings of IstioOperator are different from the fields in the helm values
• move more things from install config to runtime config to further simplify the install experience
  • e.g. a lot of today's cmdline args and ENV vars could be part of an 'experimental' section in meshconfig instead- there's really no reason why an administrator has to configure them at install time

1 on treating IstioOperator as a non-visible implementation detail (however we do that) - we already tell people not to use it, effectively, following that up by explicitly making it less visible in docs/user-facing porcelain seems good.

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.

I think there are still users of the Istio Operator as its been in the docs.

maybe we can move IstioOperator controller to istio-ecosystem org?

I think there are still users of the Istio Operator as its been in the docs.

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?

I think there are still users of the Istio Operator as its been in the docs.

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?

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

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