dotnet
Distributed Grain Directory followup work
There are some things we need to do before taking the experimental attribute off the new grain directory and eventually making it the default.
- Implement a relatively smooth rolling upgrade strategy from the old directory to the new one. One idea is to implement the old grain directory system target interfaces in the new grain directory.
- Reduce log noise. Most info and even warning level logs can be made debug logs.
- Enable the directory everywhere, even with no grains using it.
Looking forward to this. I've using 3.x for a few years with k8s rolling upgrade deployment without no major issues. I tried to upgrade to 8.2 and then 9.1.2, and I tried both using default grain directory and redis grain directory, but I still face the issue that there is a chance that after the k8s rolling upgrade, several grains stoped responding to other client/grain calls. Causing large number of orleans call message timeouts.
@shykln you can use the new grain directory today: siloBuilder.AddDistributedGrainDirectory()
@shykln you can use the new grain directory today:
siloBuilder.AddDistributedGrainDirectory()
Hi @ReubenBond , sorry I forgot to mention, I tried that too. I still face K8S rolling upgrade issue time to time.
@shykln thanks for letting us know. If you would like, please open an issue with details and we will help investigate.
Can we use it across different serviceId, to achieve smooth blue-green deployment?
Can we use it across different serviceId, to achieve smooth blue-green deployment?
I don't think I can. Using a different serviceId means that you are allowing duplicate activation or grains. That would break business requirements.
Hi @ReubenBond , could you help update the latest progress/plan of this work item?