-
Notifications
You must be signed in to change notification settings - Fork 7.6k
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
Prevent ossification of ambient #43614
Comments
I think most impact will be to have alpha/experimental off by default, with narrow opt-in ( workload ) and clear experimental- prefix. We can also have an install mode that clearly indicates it's experimental and unsupported and allows broader use for testing. |
@costinm what does this include? Labels, annotations, headers, API's? Waypoint/Gateway naming (GatewayClassName for instance)? |
It may ne better to identify first what we do want to treat as stable:
I think most install options, labels, annotations are to be treated as experimental - for a long time we had the goal to either promote to CRD and beta or deprecate. That probably won't work for sidecar/original Istio, but may work for ambient if we start right. |
not stale |
not stale |
As we are now moving towards Beta, I imagine we can close this issue. Please re-open if you disagree. |
In ambient, we have made a lot of design decisions, from behaviors, APIs, headers, etc. All of this is "alpha". Given the size and scope of these changes, and that we probably only have one opportunity to "get it right", it's critical that we can make the right decisions.
IMO, this can only reasonably done through iteration. Theoretically the feature progression between alpha beta stable provides this. In practice, things have been historically locked in after the first alpha release (1.18 for ambient).
To avoid this, we should make explicit measures to avoid ossification in ambient so that we have flexibility to make required changes.
Ideas:
cc @costinm
The text was updated successfully, but these errors were encountered: