I have a service fabric application type deployed to a cluster. This is working ok. I have recently refactored the code and and changed the deployed application-name from A.. to B.. i.e. changed the application name in the type. After deploying to the cluster the following error is shown:
The update of 'ServiceTypeName' is not allowed. Current value 'A..' , Target value 'B..'. (Code: UpdateNotAllowed).
Any idea how to fix it I have tried deleting the old application type from the cluster before the update but that hasn't help.
Deploy a new instance (instead of upgrading) and use backup & restore to copy the data.
Related
I have created a Proxy Service and place it as a CAR application into the WSO2 Micro-Integrator 1.2.0 in the path /home/wso2carbon/wso2mi-1.2.0/repository/deployment/server/carbonapps. I can query the new proxy service without any issues, but when I delete the CAR application and replace it with a new version of the CAR, I got an error in the Micro Integrator:
...
Caused by: org.apache.synapse.deployers.SynapseArtifactDeploymentException: ProxyService named : MyCustomProxyService already exists
at org.apache.synapse.deployers.AbstractSynapseArtifactDeployer.handleSynapseArtifactDeploymentError(AbstractSynapseArtifactDeployer.java:482)
at org.apache.synapse.deployers.ProxyServiceDeployer.deploySynapseArtifact(ProxyServiceDeployer.java:66)
... 20 more
I thought that by removing the CAR application, it would delete the Proxy Service, but clearly is not working like this.
If I delete the problematic CAR application and restart the WSO2 Micro-Integrator service, then, when I place the new CAR application (again), the error is no presented.
Is there a way to clean any installed Proxy Service (CAR Application), without restarting the WSO2MI server?
When you delete the carbon application all the deployed artifacts should be removed from the server and according to your issue description, it seems the hot deployment feature is not working. However, When I checked this locally in both fresh and updated WSO2:MI-1.2.0 pack, I am able to deploy the same changed car application without any server restart. So please download the LATEST RELEASE: 7.1.0 from the official site[1] and try it again.
I have created a Service Fabric cluster in Azure from scratch, with security provided by an X509 certificate. There is one node type with five nodes, all of which appear healthy when I look in Service Fabric Explorer.
I have a solution in Visual Studio 2017 (v15.3.5) containing a Service Fabric project along with one other project which is a Stateless Service. When I attempt to deploy this, I select the cluster in the publish window, and hit go.
It then sits indefinately displaying "Started executing script 'GetApplicationExistence'" in the Build output window in VS. No amount of waiting will result in either success nor an error message. I can't find anything in the logs in Azure.
Does anyone have any idea what could be going wrong?
Check if your LocalCluster is healthy. There should not be any error/warning. I had warning System/DnsService was not up.
Reset the LocalCluster worked for me.
It turns out that there was something wrong with my development environment; the service fabric installation had got messed up somehow. When I tried with the exact same code from a different machine it all worked properly. I updated the Service Fabric elements of Visual Studio to the latest version and all started working again.
In Service Fabric cluster, If application has multiple versions(say 1.0.0,1.0.1,1.0.2), then how can we shift the application to one version to another version(say active is 1.0.0, then I wanted to shift to 1.0.1) with out redeploying the application. Is there a PowerShell command to do this?
You should be able to use the PowerShell command
Start-ServiceFabricApplicationUpgrade
This being said I did hit an issue with my local cluster, telling me I couldn't upgrade / roll back the application if the service description had changed, which it hadn't. Using an Azure hosted cluster this worked as expected, perhaps an inconsistency with how the package is copied into the image store.
Depending on what you are attempting to achieve you could also look at named instance where you are able to deploy multiple versions of an application at once, for A - B testing.
Here are some similar posts:
Post 1
Post 2
EDIT:
Thanks to Aleksey L for the comment below. With a bit of messing around due to types not being the same and as long as you haven't changed any parameters between versions this will work,if you have you will need to manually build up the hash table.
The following post (on stackoverflow.com):
Design of Application in Azure Service Fabric
suggested that it is possible to have side by side installation of same application type with a different version. I tried to install a new version of application (fabric:/ServiceFabApp1 with a new version of 2.0.0 and of ServiceFabApp1Type) on my local cluster (that already has same application name with same application type with version 1.0.3 i.e. fabric:/ServiceFabApp1 with a existing version of 1.0.3 and of ServiceFabApp1Type) and got following error:
An application with name 'fabric:/ServiceFabApp1' already exists, its Type is 'ServiceFabApp1Type' and Version is
'1.0.3'.
You must first remove the existing application before a new application can be deployed or provide
a new name for the application.
Is this by design that application type (for multiple versions) can be same but the application name must be different for each version? Or it simply does not work on the local cluster but works in the azure cloud? Or is my interpretation of the information in the above link is incorrect?
Application types (eg. ServiceFabricApp1Type) can have one or more versions but an application instance (eg. fabric:/ServiceFabricApp1) can only be running one version at a time.
Thus, if you want to have two different versions of your application type running in your local cluster, you will need two different application instances, such that you can have, say, fabric://ServiceFabricApp1 running version 1.0.0 and fabric:/ServiceFabricApp2 running version 2.0.0. The easiest way to do this with the VS tools is to create two application parameters files, each of which defines a distinct app instance name. You can then choose which of the current instances to target with the current version that you're building. To move back and forth between versions of the type in VS, you'll probably want to just create a branch for each.
When you deploy a SF application, there are several steps:
1. Copying application package to the service SF image store
2. Provision application
3. Deploy/upgrade application
Step #1 is just copying the package to the SF cluster image store.
Step #2 provisions a new version of the application so that SF can either deploy that application, or upgrade an existing application if it has already been deployed.
Step #3 depends on what you've done before. If you have already deployed version X of your app, you can't deploy version X+1. You can only upgrade/downgrade.
If you need to run multiple instances of applications with the same version, you'll need to create different packages where name of the app is a unique name (a multi-tenant scenario).
I've upgraded Azure Storage Emulator from 2.3 to 2.4. WAStorageEmulator.exe has been renamed to AzureStorageEmulator.exe but that's not the issue.
When I run
AzureStorageEmulator init -forcecreate
I simply get an error that Google returns with zero results:
Error: User-specified instance not found. Please correct this and re-run initial
ization.
Edit
I had to do a start and stop and then I was able to init. Because I had previous version of emulator installed I already have WAStorageEmulatorDb34 on my local SQL server instance. After I run init command I can see that no new database is being created (like WAStorageEmulatorDb42).
So I thought that the newest version may be using older DB. I then ran a query in MSSMS to check for existing blob containers and I can still see both containers I created on the older emulator containing blobs I added.
When I then accessed Development Azure Storage in Visual Studio it showed no containers whatsoever. So the new version apparently doesn't use old DB. But which one? And where is it?
Ok so I thought I'd run init one more time but with additional parameters to put DB on my SQL server instance:
AzureStorageEmulator init -server localhost -sqlinstance MSSQLSERVER -forcecreate
And then I get the aforementioned error. Again...
I'm running CMD as admin with elevated permissions.
Solution that eventually worked
Additional info
Azure Storage Emulator normally creates tables in the LocalDB storage. Depending on the emulator version these may be in various DB instances. You can check each storage emulator version's configuration in
%USERPROFILE%\AppData\Local\[AzureStorageEmulatorFolder]\*.config
Different versions have different folder names from DevelopmentStorage, WAStorageEmulator to latest (4.2) AzureStorageEmulator.
In this subfolder you'll find at least one config file that will correspond to your installed Azure storage emulator's version. If you open it, you'll see how it's configured and where it saved its tables. This is also true if you create initialization on any existing full SQL server instance.
The problem when I was trying to initialize my Azure Storage Emulator (ASE) is that I was also providing SQL server's instance which is the default one (MSSQLSERVER). I shouldn't be providing this information in the first place but only provide information about server
So the correct command line call is
AzureStorageEmulator init -server localhost -forcecreate
This created my database on my local SQL server. From here on, it's up to you how you'll migrate from an existing ASE database (if you already had one before) to the new one.
The issue I ran into is more or less an user error.
Azure Storage Emulator 4.6
Error : User-specified instance not found. Please correct this and
re-run initialization.
and
Resolution : I didn't have a windows authenticated login to my local
sql instance.