Service-fabric: Service Fabric Upgrade Fails for Stateful services when the two versions are incompatiable

[muradkhateeb78]

Hi,

I have an application that contains a mix of stateful and stateless services. I had been using the service fabric upgrade to roll the new changes in my application deployed in DEV, QA and PROD. Recently I had to change the the schema of the class that was being used to saved data in the reliable collection by one of the stateful services. Following are the changes that I made.

1. I changed the name of the class
2. I removed a couple of existing data members
3. I added a new data member (A non-primitive type)

This made the two versions incompatible consequently leading to the upgrade being failed. The class in the already deployed version doesn't have the data contract enabled so I think using data contract in the newer version might not be an option here. The other option could be using a two phase upgrade and I am uncertain on how to go about using the two phase upgrade on the problem at hand. There is very less documentation available on how to approach a multi phase upgrade. What solution would you suggest to this problem?

[abarberenaCPDS]

Hey @muradkhateeb78, I've seen in this situation before and I can advise you the following:

Please check the book Programming WCF Services from Juval Lowy, check the chapter for Data Contracts. It provides a great info about about Data Contract Versioning and its DTO evolution.

It will give you a good idea and guidance about how to avoid the 'God object' anti-pattern.

Also, when deploying a SF service, when there's a class library that has all the data contracts, it's recommended to change the application deployment from 'Upgrade Application' to 'Remove Application' so it updates all its dependencies.

Please give it a try and let us know that found!

Thx!

[muradkhateeb78]

Thanks a lot @abarberenaCPDS for the advice.

Talking about the data Contracts, we don't have the data contracts enabled in our class (Deployed) that is being used for reliable collection schema. Also, we can't push the contracts now as we have our changes in master repository and we have some limitations in reverting back those changes. Anyways, as you suggested, I will go through the said chapter to see if I am missing on something.

Secondly, Due to the criticality of the data stored in the reliable collection, we can't afford for now to deploy the application in Remove Application mode. We have to make sure it gets upgraded, rather than redeployed.

[masnider]

Yes you can easily accidentally cause your services to become unavailable or corrupt state when changing your services if you don't follow the prescribed procedure. In addition to the book that @abarberenaCPDS points to, some good guidance is in the following docs.

https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-services-reliable-collections-serialization

https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-services-reliable-collections-guidelines

Please also see this tool and give it a try and provide feedback: https://github.com/hiadusum/ReliableCollectionsMissingTypesTool