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!
Related
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.
I have tried to upgrade to the ne version of the Service Fabric preview code - 1.4.87-preview - and everything seems to have gone ok, but when I try to deploy a service I get an exception on run telling me that it cannot find FabricRuntime.dll. This goes both for my upgraded project, for newly created test projects and for all samples.
I can see that the DLL is present on the machine and that a system PATH has been set to the directory containing it.
There seems to be nothing wrong with my applications per se, as they deploy fine to a Party Cluster.
Anybody have any idea what is going on. Everything worked fine when I ran the old Service Fabric install. I have tried uninstalling service fabric and installing again, but it didn't help.
The answer is now posted on MSDN forums at https://social.msdn.microsoft.com/Forums/azure/en-US/6c8cc261-6c84-4097-be03-e8073cbc9397/unable-to-load-dll-fabricruntimedll?forum=AzureServiceFabric&prof=required
Copy of answer from MSDN Forum:
This is happening because FabricRuntime.dll is looking for zip.dll that ships with Service Fabric runtime. However since JRE is ahead in the PATH list and it also ships with a zip.dll, FabricRuntime tries to load zip.dll from the JRE folder and fails. We have fixed this issue by renaming our DLLs. The fix will be available in the next update of the SDK. In the meanwhile, you can fix this by adding "C:\Program Files\Microsoft Service Fabric\bin\Fabric\Fabric.Code" as the first entry in the system path and then restarting the machine.
This is the SDK issue, I've opened a GitHub issue at here
I noticed this afternoon that my Bluemix IoT Application was in the 'Unknown' state. When I mined into the app to see what the problem could be, I got the following pop-up:
App staging failed in the buildpack compile phase
I haven't made any changes to my NodeRED flows in months, and if I spin up a new IOT Foundation app, it starts just fine.
Any ideas on what is going on here?
A recent update to the underlying application stack has caused an incompatibility with older versions of the IoTF boilerplate.
The fix is to edit your application's package.json file and remove the 'mqlight' entry under the dependencies section. New instances of the boilerplate already have this entry removed - hence why they work.
Perhaps check the bluemix server status at https://developer.ibm.com/bluemix/support/#status
There were some issues reported around scheduled maintenance. There are also buildpack updates scheduled.
We upgraded firewall firmware on servers, and the firmware update contains shellshock protection.
Suddenly whenever we do deploy with Capistrano the firewall block our office so we get "Blocked because of IPS attack" from firewall.
I bundle update Capistrano and all dependencies to latest version and same result. Anyone had and know fix for this issue ?
my versions
capistrano (3.2.1 8290d3f)
capistrano-bundler (1.1.3)
capistrano-rails (1.1.2)
capistrano-rbenv (2.0.2)
The problem was me being too stupid. Few weeks ago I installed extension to my browser for specifying custom headers. I created some custom malicious headers and was trying to crack my page to see what will happen. Of course I forget to turn it of.
each time I was doing deployment I checked it with the web-browser (with faulty extension) therefore locking my access and blaming it on deployment.
more info here https://github.com/capistrano/capistrano/issues/1176#issuecomment-62020915
I have a PHP Azure project which I have to manage with Powershell cmdlets. One of these, Publish-AzureServiceProject doesn't seem to be detecting file changes so these are not updated on the cloud (even though no errors are displayed).
I have remote desktop'd into the machines and the code is definitely not updated from weeks ago.
If I deploy to the local emulator, it is fine but this is much more obvious because it displays "removing old package" and "creating local package". The cloud package definitely contains the latest files, so the packaging is working fine.
Can anyone tell me how to force the publish to update the files on the cloud and more importantly, why this is not happening? Also, if I force the update, will it deploy to a new box and get a new IP Address?
Thanks.
It seems to work now.
I have removed and reinstalled azure libraries from my machine and created a new project from scratch and copied the original files over into it. I have not included diagnostics (not sure if that's an issue) and I have modified the Publish-AzureServiceProject script to select the subscription each time before it publishes.
It is possible that the subscription confusion was not helping (I have two Azure subscriptions and it might have used the wrong one at some point and done something weird) and also it was possible there was some conflict with various versions of the Azure SDK since I have been using it for over 6 months but at the moment, all is good.
A related article on my blog here: Problems with PHP Azure
Thanks for the interest