Azure-functions-host: Validate Azure Files storage account

[btardif]

_From @fabiocav on February 16, 2018 1:13_

Today, if a customer deletes the storage account backing the content share, the function app is left in a broken state and the portal doesn't show any information about what is going on.

It would be good if the portal could validate the storage account when failures to talk to Kudu occur (calls to getfunctions, etc) so we can provide a detailed message to the customer so they know what needs to be done.

_Copied from original issue: Azure/azure-functions-ux#2355_

[btardif]

@jeffhollan I think this check should be performed by the backed and provide a property we can check.

There are a few reasons why a function could be in a broken state, and this is just one of them.

Also if this is provided by the backed then other clients beyond portal can surface this information by checking that property.

If you agree can we move this to the run-time repo and I'll file a UX work-item to consume the property once the change is done?

[btardif]

_From @jeffhollan on June 13, 2018 9:11_

I tend to agree with @btardif on this one. I expect what's happening is the portal is making a call to something like /GetFunctions and is getting back some non-descript 500 Internal Server Error. (or something)

I do think the best place to track a fix would be on the API layer so that /GetFunctions would return something like "Cannot retrieve functions as there is no associated file share or storage account" (or something). Do think next actionable thing would be a bug on the scm? layer to surface errors for the UX instead of making the UX have knowledge of failures. @fabiocav thoughts?

[fabiocav]

That is not a host API, so it would need to be a Kudu change. In order to detect the scenario described in the original issue, the ability to check if the resource was deleted is needed, which is something the host doesn't have.

The entire site might be in a bad state if DWAS is unable to mount the share, though, so it's tough to say whether the current backend APIs could be enhanced to provide this information.

We need to investigate something with Monitoring/Notifications (something DWAS can consume), but I'm not an expert there.

[fabiocav]

@jeffhollan following up on the conversation we had. This is not something that can be done by the backend APIs we have today, as they will not be operational in this scenario. If we can't have the portal handle that for now (which I agree, is not ideal), there isn't much we can do for this issue right now and we need to (unfortunately) close this issue

[jeffhollan]

Thanks @fabiocav -- @btardif thoughts? We see a healthy number of support tickets every month from this issue so while not ideal I would prefer we solve this on the UX if it gives us the best shot to get it working shorter term.

[btardif]

@jeffhollan can you setup a meeting to go over our options here, see if we can whiteboard a solution and then figure out implementation. Include me and @agruning form UX side and I guess you and @fabiocav from backed should be enough 🤞

[jeffhollan]

Work completed and live :)