Why can’t I change the placement restrictions during the upgrade?

Question

I have a standalone ASP.NET Core service (RC1) running in my Azure Service Fabric cluster. It has the following manifest:

<ServiceManifest Name="MyServicePkg" Version="1.0.2" ...> <ServiceTypes> <StatelessServiceType ServiceTypeName="MyServiceType" /> </ServiceTypes> ... </ServiceManifest> 

My cluster has hosted properties configured. I have 5 servers with "nodeType = Backend" and 3 servers with "nodeType = Frontend".

I would like to update my service and indicate that it can only be hosted on the Backend nodes. This is my updated manifest:

 <ServiceManifest Name="MyServicePkg" Version="1.0.3" ...> <ServiceTypes> <StatelessServiceType ServiceTypeName="MyServiceType"> <PlacementConstraints>(nodeType==Backend)</PlacementConstraints> </StatelessServiceType> </ServiceTypes> ... </ServiceManifest> 

However, if I am currently updating, I get the following error:

Start-ServiceFabricApplicationUpgrade: default service descriptions should not be changed as part of the update. Changed default service: Fabric: / MyApp / MyService

Why can't update restrictions be updated?

Should I delete and re-create the service? This would seem very problematic for me, because it will lead to downtime and data loss for stateful services.

Answer 1

Actually a pretty simple way to do this without having to write a bunch of code to manually identify the application in the cluster.

While you can declare placement restrictions in a service manifest, you can also declare them in an application manifest. Anything declared in the application manifest will override what is in the service manifest. And with customization in the application manifest, you can use parameters to change values ​​based on the parameter file that is required for a specific deployment.

I just wrote a blog post discussing this approach in more detail . Hope you find this helpful. :)

Answer 2

So the problem here is that part of the DefaultService ApplicationManifest. When services are created as part of the DefaultService, there are things that you cannot change after that. You may be able to modify it through the ServiceFabric Explorer, but I'm not sure.

One recommendation would be to leave DefaultServices empty in ApplicationManifest and instead create your services manually. With manual, I mean either through powershell, either in code or in ServiceFabric Explorer. This gives you more flexibility with regard to changing parts of the service after that. When this is done, you know that you have the ability to change things such as placement restrictions after the service is started.

To create services using PowerShell, you can use the New-ServiceFabricService . To create it from code, you can use FabricClient for this. An example of this can be found here: Multisite Azure Communication