Open johncrim opened 5 years ago
The service should depend on the application resource, not on the applicationtypeversion resource. Please see this sample template from the managed identity walk-through, and see if this resolves your issues.
Thank you for the reply @amenarde . Just to clarify, the error I was getting when using the dependency on the application resource was:
// Include the following, for:
// Error: Code=InvalidTemplate; Message=Deployment template validation failed: 'The template resource 'testme-stage/APPNAME/SERVICENAME' at line '174' and column '9' is not valid: The resource identificator 'testme-stage/APPNAME' is malformed. Please see https://aka.ms/arm-template-expressions/#reference for usage details.. Please see https://aka.ms/arm-template-expressions for usage details.'.
//"[variables('appResourceName')]"
I have not tested this again since posting the issue, but the workaround of omitting the Microsoft.ServiceFabric/clusters/applications/services
resource is working acceptably. I wouldn't be surprised if this problem still exists, but it doesn't seem to be bothering many other people.
I have not been able to successfully deploy an ARM template for a new SF app containing both a
Microsoft.ServiceFabric/clusters/applications
resource and aMicrosoft.ServiceFabric/clusters/applications/services
resource, as documented here.Repro steps:
Microsoft.ServiceFabric/clusters/applications
resource and aMicrosoft.ServiceFabric/clusters/applications/services
resource, where the services resource describes the SF service within the application.I have tried all of the following options for the
"dependsOn"
: block:The below file “ServiceFabricApplication.jsonc” contains comments showing all 3 options, none of which work. I have also tried specifying the service resource as a child resource of the application (which seems like the best model), but it also fails with the circular dependency error.
The only workaround I can find is to omit the
Microsoft.ServiceFabric/clusters/applications/services
resource; another workaround might be a 2 step deploy (deploy 1 ARM template containing theMicrosoft.ServiceFabric/clusters/applications
resource; the deploy a 2nd ARM template containing the aMicrosoft.ServiceFabric/clusters/applications/services resource
) – I have not tried this. But this is clearly a significant bug, because what the documentation directs developers to do does not work.Here's an ARM template that fails to deploy (though any ARM template containing a
services
resource should fail):