Why isn't it possible to change placement constraints in an upgrade?

Question

I have a stateless ASP.NET Core (RC1) service 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 is configured with placement properties. I have 5 servers with "nodeType=Backend" and 3 servers with "nodeType=Frontend".

I would like to upgrade my Service and specify that it may only be placed on "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 now execute the upgrade, I get the following error:

Start-ServiceFabricApplicationUpgrade : Default service descriptions must not be modified as part of upgrade. Modified default service: fabric:/MyApp/MyService

Why isn't it possible to change the constraints with an upgrade?

Would I have to delete and re-create the service? This would seem extremely problematic to me because it would result in downtime and data loss for stateful services.

Answer 1

There's actually a fairly easy way to do this without having to write a bunch of code to manually define the application on the fabric cluster.

While you can declare the placement constraints in the service manifest, you can also declare them in the application manifest. Anything declared in the application manifest will override what's in the service manifest. And with the setting in the application manifest, you can then use parameters to alter the values based on the parameter file you want to a specific deployment.

I've just written up a blog post that discusses this approach in greater detail. I hope you find it useful. :)

Answer 2

So the issue here is actually with the DefaultService part of the ApplicationManifest. When services are created as part of the DefaultService, there are things you can't change about it afterwards. You might be able to change it through the ServiceFabric explorer, but I'm not sure.

One recommendation would be to keep the DefaultServices empty in the ApplicationManifest, and instead create your services manually. With manual I mean either through powershell, code or the ServiceFabric Explorer. That gives you more flexibility about changing parts of the service afterwards. When it's done that way, you I know you have the possibility to change things like placement constraints after the service is running.

To create Services with PowerShell you can use the New-ServiceFabricService command. To create it from code, you can use FabricClient to do it. A sample of that can be found here: Azure Service Fabric Multi-Tenancy