I have a Service Fabric application with a few services underneath it. They are all currently sitting at version 1.0.0.
I deploy an update out to the cluster for version 2.0.0. Everything is running fine and the deployment succeeds. I notice a very large but in the version. Is there a way to manually rollback to version 1.0.0? The only thing I have found is automatic rollback during an upgrade.
Matt's answer is correct, but I'll elaborate a bit on it here.
The key is in understanding the different steps during application deployment:
Copy
Register
Create
Upgrade
Visual Studio rolls these up into single "publish" and "upgrade" operations to make it easy and convenient. But these are actually individual commands in the Service Fabric management API (through PowerShell, C# or HTTP). Let's take a quick look at what these steps are:
Copy:
This just takes your compiled application package and copies it up to the cluster. No big deal.
Register:
This is the important step in your case. Register basically tells the cluster that it can now create instances of your application. Most importantly, you can register multiple versions of the same application. At this point, your applications aren't running yet.
Create:
This is where instances of your registered applications are created and start running.
Before we get to upgrade, let's look at what's on your cluster. The first time you go through this deployment process with version 1.0.0 of your application (call it FooType), you'll have just that one type registered:
FooType 1.0.0
Now you're ready to upgrade. You first copy your new application package with a new version (2.0.0) up to the cluster. Then, you register the new version of your application. Now you have two versions of that type registered:
FooType 1.0.0
FooType 2.0.0
Then when you run the upgrade command, Service Fabric takes your instance of 1.0.0 and upgrades it to 2.0.0. If you need to roll it back once the upgrade is complete, you simply use the same upgrade command to "upgrade" the application instance from 2.0.0 back to 1.0.0. You can do this because 1.0.0 is still registered in the cluster. Note that the version numbers are in fact not meaningful to Service Fabric other than that they are different strings. I can use "orange" and "banana" as my version strings if I want.
So the key here is that when you do a "publish" from Visual Studio to upgrade your application, it's doing all of these steps: it's copying, registering, and upgrading. In your case, you don't actually want to re-register 1.0.0 because it's already registered on the cluster. You just want to issue the upgrade command again.
For an even longer explanation, see: Blue/Green Deployments with Azure ServiceFabric
Just follow the same upgrade procedure, but targeting your 1.0.0 version instead. "Rollback" is just an "upgrade" to your older version.
Related
I have noticed that when I upgrade my application containing a stateful service fabric will, as needed, promote old versions to primary to clear the path for upgrading a domain.
This ends up problematic when there is a non-backwards compatible release being pushed out. For instance, lets say my services query a database as they are promoted to primary. If I push an older release where a recently added database column is absent, the database roles back to that version and removes the column. Then during the upgrade fabric attempts to promote an old instance to primary, but that fails because the old instance is looking for the column that is no longer present in the database. This causes the whole upgrade to fail.
Is there anyway to upgrade the application but avoiding fabric promoting the current (pre deploy) version of my service to primary?
Is there a possibility to deploy only Application Parameters (cloud.xml) somehow without having to redeploy the code or upgrade the application version? For example after deploying the Application on Service fabric cluster, there could be a minor thing I might need to change in one of the parameters in cloud.xml. And it won't make sense to upgrade the version of the Application for this minor change.
I have combed through various sites but did not find anything suitable.
I'd say - no, you can't do this. Here is what Service Fabric application upgrade says on this -
During an upgrade, Service Fabric compares the new application manifest with the previous version and determines which services in the application require updates. Service Fabric compares the version numbers in the service manifests with the version numbers in the previous version. If a service has not changed, that service is not upgraded.
After upgrade to sdk 2.5.216 and runtime 5.5.216 Test-ServiceFabricApplicationPackage command works only for complete package. In case of partial app upgrade (some Pkg are removed) it results in "Windows PowerShell has stopped working". I have tested on several computers and several apps. to reproduce:
create test app with 2 services and deploy.
change app version and particular service version.
create package and remove Pkg folder from it for the service without modifications.
connect to Service Fabric and test like Test-ServiceFabricApplicationPackage -ApplicationPackagePath "..path" -ImageStoreConnectionString "fabric:ImageStore"
Maybe somebody was able to overcome this issue? or at least has similar behavior so I'm not alone in Universe.
Thanks!
Alex
Take a look at https://github.com/Azure/service-fabric-issues/issues/259
This is a bug in our code. It happens when a compressed package was uploaded and provisioned in the cluster. Testing a new version of the application fails because settings file was not found in the provisioned version.
We fixed the issue and it will become available in one of our next releases.
Meanwhile, you can skip compression or test the version 2 application package without passing in the image store connection string.
Apologies for the inconvenience!
In experimenting with a sample SF app and playing with upgrades and versioning I am noticing that it keeps a rather long history of versions. Below is a screenshot of my app in SFExplorer. Is there any way to control how much history is retained, or can I cull out versions I'll never use again.
Or should I not even be concerned with this? (even though I am!)
What you're seeing here is application registration. Before you can create an application instance, you have to register the application type and a version. When you upgrade your application, you register a new version of the same application type. This is the PowerShell command that does it (Visual Studio uses this on your behalf when you upgrade through it):
Register-ServiceFabricApplicationType
Over time, you'll see a bunch of versions of your application registered. If you don't want them registered anymore, you can simply unregister them using the corollary command:
Unregister-ServiceFabricApplicationType -ApplicationTypeName SFDemoType -ApplicationTypeVersion 1.0.2
While we have that screenshot in front of us, here are a couple cool things about application registration:
You can create instances of any registered application type + version at any time with the new commands:
New-ServiceFabricApplication -ApplicationName fabric:/SFDemo2 -ApplicationTypeName SFDemoType -ApplicationTypeVersion 1.0.7
This means you can do cool things like create side-by-side instances of the same application type but of different versions. Say you want to test out a new version of an application without upgrading an existing instance yet. You can register the new version, but instead of upgrading an existing instance of that application type, you can simply create a new instances of the new version of the application type.
You can "upgrade" a running application instance from any version of an application type to any other version of an application type using the upgrade command:
Start-ServiceFabricApplicationUpgrade -ApplicationName fabric:/SFDemo -ApplicationTypeVersion 1.0.20 -FailureAction Rollback -Monitored
For example, say you just upgraded your application instance from 1.0.15 to 1.0.20. After a while, you find a bug in 1.0.20. You can use the same application upgrade command to "upgrade" back to 1.0.15. In fact, the version strings are just strings - they can be anything you want. You can upgrade from version "banana" to version "Tuesday" if you want!
So yeah, you can unregister old versions if you think you'll never need them again. But it's great to have a version history, because you can actually do interesting stuff with it!
In an Actor project, the AssemblyVersionAttribute value is used to update the ServiceManifest version, along with the code and config version. There is no such behavior for Service projects.
This updated version is also used to update the ServiceManifestRef 's ServiceManifestVersion reference in the ApplicationManifest. While the ApplicationManifest is modified on every build, it doesn't appear a manually set version within the Service project's ServiceManifest is updated in the ApplicationManifest either.
Is this planned or intended behavior for Service projects?
I'm running Visual Studio 2015 RC, the first preview of the Service Fabric SDK, and 4.0.95-preview1 of the NuGet packages.
Short answer: This behavior difference is temporary as we improve our tooling support for versioning and upgrade.
Slightly longer answer: Part of the original goal of the Service Fabric actor framework was to abstract away the details of manipulating the application and service manifests so that you can truly focus on your business logic. Hence, the SDK includes a tool (called FabActUtil) which is responsible for doing some of that manipulation on your behalf as a post-build step. There is currently no such tool for reliable services projects. We are considering options for reconciling this difference as part of adding upgrade support to Visual Studio. We need to strike a balance between keeping you in control of your versioning scheme and taking care of the chore of cascading your version changes throughout the application as required.