Just to be clear are you still proposing that we leave things as is?
I am sure there are other options that could work, but if I were to chose I would, yes. The users of my project do not have issues with experimental - at all.
I appreciate that clarification, unfortunately I agree with Nick in that I'm struggling to see how it would be tenable.
I don't at all think this is the intent, but just to view this from my perspective, this comes off as the platform saying "I see you are perfectly happy with the status quo, but I am not, so I am going to force the APIs to change to the point where they are unusable". Why are we so keen to push a problem that (IMO) only impacts platforms onto everyone else? Why not consider the platforms taking on the burden of supporting the community? (To re-iterate, just showing my raw perspective -- I 100% understand that is (hopefully) not the actual intent).
A related question - are the platforms that are pushing for this change even going to implement all the experimental API types? I don't think I have seen any here actually indicating they would. If not, it comes across more like "removal of experimental via making it unusable so I no longer need to deal with it" than "improving experimental".
Well if it helps, I do come from the perspective of a platform (OpenShift) and so I can speak directly from my own personal perspective which will hopefully be helpful:
As Gateway API has become ubiquitous we have a requirement to ensure multiple implementations (and other projects that rely on Gateway API) can all work on the same cluster. It is not reasonable for one single implementation to be managing the life-cycle of these CRDs anymore, or users just installing them from the web, because at best other implementations could not consistently rely on what will be present for them, and at worst things could become broken. Naturally this means the platform has to take responsibility, and treat the CRDs as "core-like" APIs so that implementations can reliably depend on the API. OpenShift will be doing this very soon as GKE has been doing for some time.
So back to experimental specifically: From the perspective of the platform I work on we can actually accommodate any of the solutions to the experimental problem ("Full Copy", "New Only", or "Do Nothing") with relative ease, we just wont be providing any level of support for experimental (which is exactly how experimental should be so it's almost not worth saying). Suffice to say it's more with my maintainer hat on and a desire to protect the user and implementer experiences that I have this conversation. And from that perspective I see it as nearly the opposite of it "only impacts platforms", I see it as "only impacting implementations and users of experimental".
Given the above: In a future where "Do Nothing" can't happen (which implies separate groups happens regardless), I struggle to see a slow transition to the new group where things can be in two places is the best overall solution for everyone involved. For users I think the separation might mean they don't have to play hell to get the experimental CRDs in place on a cluster which already has the standard ones, so maybe that's nice. For implementations I rather expect they'd prefer to have one way to implement the experimental features, and not have to accommodate both the experimental channel AND the experimental group (maybe this is particularly true for new implementations, or implementations that are less invested in experimental), though I'm keeping myself aware that some implementations anticipate having to do a significant overhaul and we must include that in the discussion. The platform can easily accommodate either, but which would be best for all the users and implementations involved? Still an unanswered question in my mind.
For instance, if we could drill it down to something like "full copy for us would mean separate controllers. Because of this we anticipate 168 hours of refactoring time to update our implementation. We don't expect to have 168 hours of additional engineering time within the next 6 months", that would be helpful to understand.
The cost is indefinite. Parallel controllers doing the ~same thing, forever. I don't care about a one time cost, I would easily spend 168 hours if it solved all of our problems and then was done, but its not the case at all. The cost is ongoing and will come at a risk to our users.
We have concrete examples of doing this in the past in Istio, with Ingress v1 promotion (for other APIs we just cut over at once, but Ingress had too short of a window from v1 addition to beta removal). There it wasn't so bad since Ingress code ~never changed, and it had a lifetime of a couple releases before we could clean it up. Even in that time, we had a few bugs related to the split.
Gateway would be far different, since its one of the most actively changed areas of our codebase and has no "end" time when we can converge.
Indefinite, as in the cost continues to be paid? 🤔
Assuming we're already transitioned though, and kinda in a "steady state" the main thing that will come up is "new experimental field X has been added to resource Y, I need to add support". In that instance, the workflow is:
Aren't those steps pretty similar in either case? I mean I understand we have the initial upfront cost to convert, and when the field finally gets promoted you have to copy from experimental over to the standard implementation, but otherwise is it kind of a wash?
There's still work to be done to see if there are more viable options for supporting the separate group than just copying all your controllers, so I wouldn't count that out yet
I've considered a few of these but ultimately don't see any that aren't at risk of destabilizing our stable users (which is, of course, our top priority and something we cannot compromise on)
Ok, but if we were able to come up with a stable alternative to the "extra controllers" implementation, would this significantly improve your feelings towards having separate groups?
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4