Service-fabric: Removing an SF service and then upgrading --fails saying that we need to remove the deployed service first before we can remove the service type

[muradkhateeb78]

Hi,

We have an application with multiple stateful and stateless services. We wanted to remove one of the stateful services from our application. We did that and the upgrade failed saying that you first have to remove the service from the application deployed in the cluster. According to this stackoverflow question we know that we have two options.

1. We can remove the application manually from the SF cluster.
   We could have done that but it would not have been generic for services we may want to remove in future.
2. We can use the powershell scripts to remove the service from SF cluster.
   This approach seems to be more suitable. We can look if Publish-ServiceFabricApplicationUpgrade throws this error, we would then get the service name from the error and would try to remove that particular service from the SF cluster. This way it not only solves the problem at hand but would also be generic for future cases where we want to remove our services from the deployed application.

We wanted to apply the later solution but we were confused a bit if this was the standard practice for handling such scenarios?

[abarberenaCPDS]

Hi @muradkhateeb78, Stateful services are meant to behave like that. This means that, before coding the service, you must plan/design the partitions, ranges and Key strategy.

Once the _state_ is created, that's it! So the only way to recreate it is to create a new version of the service, which is the correct and expected behavior of a micro serviced-based approach.

The flow is, design the Version # 1 of the service and state, a change comes in or partitions need to be recreated, then add a new Version 2 of the same service to accommodate change. Also, Don't forget to decommission the old state, which is a common practice when versioning service.

That means you should use your _old version_ of your service to remove the state.

I believe SF is rightfully indicating you must remove that service, or better said, the V1 of your service.

How does that sound to you?

[muradkhateeb78]

Thanks @abarberenaCPDS.
This is exactly what we are doing, we are removing the version V1 and upgrading, since removing that serivce isn't costing us much and then we would redesign the schema for the same service, add it again and upgrade it. Hope this would solve the issue. Also we will be adding data contracts to make the future changes Forward-Backward Compatible. That seems like a proper way to handle this scenario in our case....?

[masnider]

Yes you do have to manually/explicitly remove the service instances from the application before you can remove the type. This is to prevent accidental errors which change the type from auto-deleting existing services. We don't typically recommend you "automatically" do this for this reason, deleting services should be an explicit action.

Yes, also, the recommended way is not to delete service types and create new ones but to ensure that you can always migrate your state forward/backwards, that way you can go through the normal upgrade process to evolve your services. There's some good guidance in the docs around how to do this. Strongly recommend practicing it as well as backup and restore processes before attempting in production environments.