so is sidecar mode. At least three of the charts are shared?

Does the operations docs actually talk about what you should do differently? Is it a scaling suggestion? (You wouldn't scale istio-cni and I doubt you'd scale ztunnel)

so is sidecar mode. At least three of the charts are shared?

Yeah, this is sort of boilerplate. I'll enhance to mention that some components have different impacts on app traffic and node health than others (data plane vs control plane, really) and this impacts upgrade cadence considerations.

Does the operations docs actually talk about what you should do differently? Is it a scaling suggestion? (You wouldn't scale istio-cni and I doubt you'd scale ztunnel)

Scaling, and upgrade cadence.

Really, this should link to

https://preliminary.istio.io/latest/docs/ops/best-practices/deployment/

and that should be built out. I'll do that as part of this.

Actually - what I was kinda hoping is that we could just link to wherever this #15247 ends up (under /ops/ or wherever) as the "recommended/opinionated production setup".

maybe even dropping the "individual install" instructions and just having

• simple chart install/upgrade with caveats as the landing page, which links out to...
• Expand Ambient Canary Upgrade Instructions #15247 as an "opinionated production deployment" model.

@therealmitchconnors thoughts?

Started reviewing this a bit further and realised the same thing - we need to treat all of these holistically (and think about how we're going to include this content in the general Istio install/upgrade docs as ambient moves to GA.) I'll stand down, but it would be great to get this chart included in the Getting Started guide (at least for 1.23, if not 1.22)

I don't think I meant that last part

Started reviewing this a bit further and realised the same thing - we need to treat all of these holistically (and think about how we're going to include this content in the general Istio install/upgrade docs as ambient moves to GA.) I'll stand down, but it would be great to get this chart included in the Getting Started guide (at least for 1.23, if not 1.22)

I don't think I meant that last part

Oh hello, I don't think we should be using helm in the Getting Started guide. This has to be zero to installed in as quick a time as possible.

I'd love to get updates to the Helm page in before making some updates of my own though. Could we remove this for now and just get the others?

This has to be zero to installed in as quick a time as possible.

Yes, that was the intent behind this PR. helm install istio-ambient istio/samples/ambient -n istio-system --create-namespace --wait being analogous to istioctl install --profile=ambient

I was looking at the getting started doc as the simplest possible/most normative set of steps for the non-Istio user (who probably already uses Helm).

I had the wrapper chart in the regular Helm install guide before, and was asked to move it out: #15279 (comment)

The options here are:

1. Drop the wrapper chart people have asked for, and (IMO) continue to have a needlessly substandard Helm experience, because we don't recommend/test/use/compose Helm charts the way our users do in any capacity.
2. Put the wrapper chart guide in quickstart (where this PR puts it now)
3. Put the wrapper chart guide in Helm install (where this PR originally had it, before the TOC asked for it not to be there)

@linsun @howardjohn and @craigbox you all decide, and I'll wait for that.

I think @craigbox's comment was just not to put anything 'helm' in quickstart, likely on a disagreement that its the 'simplest set of steps for the non-Istio user'.

I do tend to agree for a quickstart Helm is likely to only cause friction. istioctl is already something a user will install as part of the getting started (used in other parts), so its a decent choice -- as is kubectl apply which is what we used to do.

I don't think that means we need to drop the wrapper chart, though, we can just say you can install with helm in a aggregated or decomposed manner based on your needs

There is a disconnect here between the TOC and the "docs WG" (me), who is asleep when TOC meetings happen. I'm sorry to Ben for it having dragged him in two directions.

The goal of the "Getting Started" page is the easiest possible experience for someone looking at Istio for the first time. We're debating on Slack if this is helm or if it is istioctl, but until now we've assumed it was istioctl. Peter and I have put some effort into improving this recently as unfortunately it is a measure by which the "complexity of Istio" has been reported.

There is also a meme of "Istio has 7 Helm charts", which I am all in favour of resolving. I think that the Helm install page should point out that you can install everything with one chart, or use separate charts, and lay out the case for why you should actually do the more complex thing.

I would like the TOC (or whoever; Environments WG, Ben?) to decide on the order of recommendation for helm and istioctl, and that might dictate the choice in the Getting Started guide.

The question is -- recommendation for what goal?

For a serious production install, where we are optimizing for reliability and safety, Helm is very likely the best choice at this point. istioctl isn't bad or anything, just doesn't integrate with tooling.

For "just give me an env with it deployed so I can try it out", helm is probably not the best...

To put it another way -- when I develop on Istio, I don't use helm since it is tedious to use.

To put it another way -- when I develop on Istio, I don't use helm since it is tedious to use.

I don't use it with Istio either because it is tedious to use with Istio for reasons that have to do with Istio - I have and do use it in dev flows for other things just fine - Helm probably has more daily users than Istio does.

But all this brings up a very good point - the people developing Istio day-to-day will shave the edges off of any install mechanism we pick, no matter which is picked, in much the same way that water wears down rocks.

If we don't subject our Helm to that direct daily wear it will continue to be an afterthought and tedious to use. The same is true of istioctl.

I am convinced that the people developing Istio day-to-day (and I am including myself in this) are probably not qualified to make this decision for those reasons, and are too close to the problem to make a good assessment - so I'm gonna defer to TOC/docs WG/community asks.

Sorry for weigh in late here, my preference is to keep istioctl for getting started with ambient (same as sidecars), and add the helm wrapper also in getting started as a 2nd tab for existing helm user. That way, if people already has helm and don't want to download istioctl to get started on ambient, they can.

We do see some users asking for helm wrapper chart in ambient slack so folks will likely be using it when evaluating ambient.

Looking at the PR again, there are more lines (2X roughly i think) to read for users in the helm instruction with wrapper chart than istioctl... so I'd definitely continue to vote for istioctl. After reading the helm instruction, I lean towards to put helm get started instruction using wrapper chart as a link to be linked from the get started with ambient page.