> why it took up to 6 years for MS to release an experimental fix [1] to run on Kubernetes?
> where I can find the outstanding issue in the release notes that [1] tries to fix?
- if .NET Orleans runs fine on Kubernetes, why is there a need for an experimental fix?
There is no experimental fix, just improvements. Things which can make life easier for developers running on Kubernetes by automating some things (setting addresses), and taking advantage of information that's available in a Kubernetes cluster (whether or not a pod has been deleted) and feeding that into the cluster membership system.
The reason the latter is useful is that it addresses something which can occur during initial dev/test, but which does not come up in production cases: when an entire cluster is deleted and redeployed with the same identity, the new instances try to contact defunct instances for a few minutes as a safety measure. The enhancement is to query Kubernetes to determine if it's worth trying to contact those nodes, or whether they're almost certainly dead.
- why Microsoft doesn't write and release an Operator & Helm chart, instead asking the community?
Helm charts aren't something we see requested often. Perhaps because Orleans is a framework which is embedded into the developer's application and not a service which gets deployed and stands alone (compared to, for example, a database). There are no separate Orleans pods, just the user's application pods. Internal users have been building applications on Kubernetes with their own Helm charts. Microsoft is not asking anybody to create those things, or anything, unless they want them for themselves.
- why it took up to 6 years for MS to release an experimental fix [1] to run on Kubernetes?
- where I can find the outstanding issue in the release notes that [1] tries to fix?
- why Microsoft doesn't write and release an Operator & Helm chart, instead asking the community?
- if .NET Orleans runs fine on Kubernetes, why is there a need for an experimental fix?