API to return functions and their status

[jeffhollan]

Because there are multiple ways to set and update the disabled/enabled status for an Azure Function, it has become difficult for the UX to correctly match the status. Rather than have the portal reverse-engineer all the current and future ways, it would make more sense for the function host to have an API to return the function status' for the loaded functions (enabled / disabled) that the UX could call to render status directly from a source of truth.

[kamil-mrzyglod]

Hi @jeffhollan, since I see such similar functionality(GetFunctionStatus() action in WebJobs.Script.WebHost) is available, wouldn't it be sufficient just to update current API and instead of returning only Error in FunctionStatus, return also a status? The drawback of this solution seems to be, that one would need to query each function individually.

[peter-bozovic]

I'm also having the issue where functions having [Disabled("APP_SETTING")] attribute are marked as disabled in the Portal while they are not disabled by setting the APP_SETTING attibute to true or 1.
They are still running and we actually don't know which functions are disabled or not.

I see that the original issue https://github.com/Azure/azure-functions-ux/issues/949 is transfered here and I see it's labeled here for v2, but I wanted to check if it will be fixed also for v1 functions as we are not planning to migrate to v2 functions due to framework restrictions.

[paulbatum]

@peter-bozovic we do not expect to improve this any further for V1, as the necessary changes will be non-trivial to backport. It would be helpful to us if you could file a separate issue describing the barriers that will prevent you from upgrading to V2 when it goes GA. They might be issues that we can't really do much about (such as the availability of certain libraries on .NET core), but it would still be useful to understand..

[TiTi]

I just lost a shitload of time trying out possible values to my Disable attribute in my C# class library project.
Ended up on #949 & #2471 which lead me here.

I'm beginning with Azure function with Visual Studio, with .Net Framework (not .Net Core because preview etc...) in C# and I have to say : deployment was not a good experience...

It's all fun and games when you have a 10 lines script, but with several .cs => .dll
Publish works fine but then everything is readonly in the portal :-(
And then nightmare ensue, simply trying out to have a working ENABLE/DISABLE button which would be nice for OPS guys.

Documentation does not specify which values are expected for MY_TIMER_DISABLED, and more importantly that the GUI does not reflect this value...

For now, I've change the edit mode to ReadWrite:

[WarrenParks]

I also lost a lot of time looking into this. It's in the Important section of documentation to use this approach to disable functions. At minimum adjust the documentation and make it super obvious how it'll show up in azure.

https://docs.microsoft.com/en-us/azure/azure-functions/functions-dotnet-class-library#functions-class-library-project

[jeffhollan]

Per feedback we have improved docs to add a warning about disabling via function.json and added some clarity around how to disable.

https://docs.microsoft.com/en-us/azure/azure-functions/disable-function#functions-2x---all-languages

That said the core of the issue was around driving status from an API. If we are unifying around the App Settings approach this may be a non-requirement now, but am curious if @mathewc a status endpoint will be returned in some of the API work you have been doing

[mathewc]

We're adding both host and function status ARM APIs which the portal needs, e.g.:

GET api/sites/{name}[/slots/{slot}]/functions/{functionName}/status

{
  "id": "/subscriptions/ED8A94B8-02F3-41DC-B9E9-468F5CF5B641/resourceGroups/Default-Web-EastUS/providers/Microsoft.Web/sites/functions-app/functions/httptrigger/status",
  "name": "functions-app",
  "type": "Microsoft.Web/sites/functions",
  "location": "East US",
  "properties": {
    "errors": ["Error 1", "Error 2", ...]
  }
}

GET api/sites/{name}[/slots/{slot}]/host/default/status

{
  "id": "/subscriptions/ED8A94B8-02F3-41DC-B9E9-468F5CF5B641/resourceGroups/Default-Web-EastUS/providers/Microsoft.Web/sites/functions-app/host/status",
  "name": "functions-app",
  "type": "Microsoft.Web/sites",
  "location": "East US",
  "properties": {
    "id": "functions-app",
    "state": "Running",
    "version": "2.0.0.0",
    "versionDetails": "2.0.0.0 Commit hash: N/A"
  }
}

I agree it may make sense for us to return function enable/disable status via the function status API. We'll also be adding a first class ARM API for updating the enable/disable state.

[jeffhollan]

Ok going to keep this open for now and move to triaged (lower priority). Will watch this issue for activity to know if we should prioritize sooner than later

[tomkerkhove]

I'd like to have ARM support for this as well!

[mathewc]

FYI - the ARM API work described in #4570 addresses this. Closing this issue in favor of that tracking item.