Application/service name with . hangs during deployment

[MickBadran]

Hi folks, I've got alot of SF Service code to port over and I'm just starting out with SF Mesh (it's possible I've missrd a simple checkbox)

What I've done (vs2017/sfmeshtools - v0.9.20180718.1)

• created an empty SF Mesh API based application.
• Set the app to .netcore-2.0 as I read on the forums 2.1 win10 may deploy an unsupported image.
• published to an empty Resource Group + new Container Repository. (location: West Europe)

Been hanging here over night with the following displayed in VS.....

========== Publishing ========== Packaging Application... Building Images... Uploading the images to Azure Container Registry... Deploying application to remote endpoint...

Any thoughts would be great as I do want to get on and start some serious playing.

Cheers,

Mick.

[vipul-modi]

Can you provide the full resource id for your app? You can check the status of the deployment or any other issues by using the az mesh CLI and doing "az mesh app list".

Can you explain "Set the app to .netcore-2.0" - did you change the base image in the Dockerfile?

[MickBadran]

Thanks for the quick response.

This is the error after 2.5 hours:

Deployment 20180725101829 failed. Go to https://portal.azure.com/#resource/subscriptions/0ea15caf-6ded-43a9-ac91-38f7d7cecc0f/resourceGroups/handled-sf-mesh-DEV/deployments to view the deployment error in Azure Portal. Correlation Id: 6f21a7a7-547c-4028-b0b6-b7c80b04cfc0

I did one deployment changing the docker file to use the specific image.

I then created brand new projects in vs2017 and explicitly set 'net-core 2.0' from the drop down.

The actual reported error message from the Portal around deployment is not that detailed.

Any thoughts?

Cheers,

Mick.

[MickBadran]

looking at the app state from the CLI it says it's 'updating'

mick@Azure:~$ az mesh app list [ { "debugParams": null, "description": "handled.MDW.Calcs description.", "diagnostics": null, "healthState": "Ok", "id": "/subscriptions/0ea15caf-6ded-43a9-ac91-38f7d7cecc0f/resourcegroups/handled-sf-mesh-DEV/providers/Microsoft.ServiceFabricMesh/applications/handled.MDW.Calcs", "location": "eastus", "name": "handled.MDW.Calcs", "provisioningState": "Updating", "resourceGroup": "handled-sf-mesh-DEV", "serviceNames": [ "handledMDWCalcs" ], "services": null, "status": "Invalid", "statusDetails": null, "tags": {}, "type": "Microsoft.ServiceFabricMesh/applications", "unhealthyEvaluation": null } ]

[vipul-modi]

There does seem to be some issue on the backend that I need to follow up. Please leave the app in this state if you can.

[MickBadran]

No problems - will do. Many thanks.

[vipul-modi]

@MickBadran - I should have noticed that you have dot in the app name. Please remove that and try again.

I checked the backend and we are failing to provision the app due to this, but the microservices that interact with the end cluster is not handling the error message correctly to provide you the right error message and keep retrying.

[vipul-modi]

The "dot" is not allowed to ensure that the DNS resolution works across applications. The DNS name for the service is "service.app", having app containing additional names does not work for cross application resolutions through DNS.

[MickBadran]

ok - thanks, is it the SF Mesh application name of

handled.MDW.Calcs

or the service name of

handledMDWCalcs

I'm suspecting the former - great to know these things :)

I'll give it another go and many thanks,

[mattrowmsft]

Application name would need to be handledMDWCalcs

[MickBadran]

FYI - after removing '.' (dots) from the name all is working as expected.

Thanks guys - awesome!!!!

[mattrowmsft]

I'm going to leave this open to track fixing this to fail with a good error message.

[tomkerkhove]

Nice find @MickBadran I think this is also why my application is failing - Will try today

[tomkerkhove]

Fixed my issue as well, nice find.

Will there be validation for this in the future?

[boppbo]

Can you confirm that underscores aren't allowed in names, too? The "1.0.0-preview1"-VS-Template generated undescores for dots in project names and I suspect them the cause for failed deployments.

There should be more verbose error messages. Locally only the gateway name caused problems, underscores in applications / services worked fine. During deployment to Azure the gateway name broke the build without any helpful error message. The underscore in application name got caught with a helpful error ("One or more resource names used when creating DNS entries would produce an invalid DNS label.[...]")

[mattrowmsft]

@arturenault can you follow up on validation for gateway resource?

[arturenault]

Fix has been checked in for gateways.