Azure-functions-host: Is there a way to disable all functions in a deployment slot?

[xt0rted]

Is there a similar setting to WEBJOBS_STOPPED that can be turned on and it'll disable all of your functions from running? My project is node based if that matters.

I'm trying to change my deployment process to use a deployment slot, auto swap, and zip push. I'd like to turn the functions off in the staging slot once this is working. I could setup a secondary storage account for the staging slot, but since this is just a deployment target for auto swap it'd be much easier to just turn them all off with a slot setting.

I also don't want the old version of my functions running along side the production version post swap. For my web apps I set WEBJOBS_STOPPED to 1 in the staging slots but that didn't seem to do anything for my functions app.

[pragnagopa]

We recently fixed an issue related to this: #1331 .
@alrod - Any ideas on how to disable all the functions in a slot?

[alrod]

For 1.x runtime disabling functions for a slot is not achievable.
For 2.x runtime functions are disabled by modifying app settings which is slot sticky approach. So you can move your function app to 2.x and disable all functions in the portal for staging slot one by one. Note if you deploy function with new name to staging slot it will be enabled and 2.x is in preview state.

https://docs.microsoft.com/en-us/azure/azure-functions/functions-versions

[pragnagopa]

@xt0rted - Closing this issue. Please reactivate if disabling each function in a slot does not work for your scenario.

[xt0rted]

Disabling them one by one is going to get really messy as new functions are added. Right now I have 10 functions with another 6 being added in my next update and more to follow. It would be much easier if there was a single setting that could disable them all.

Doing them one by one will have to do for now though. Is there documentation on how to do that?

[pragnagopa]

I will keep this issue open to track adding a setting to disable/enable all functions in a given slot.

[crowbarsolutions]

Edit: after some confusion I got the suggestion above to work. You need to disable each function in your staging slot individually. Once that is done, go into your staging slot's application settings and notice that there are new settings listed, named AzureWebJobs.FunctionName.Disabled, one for each of your functions. You need to enable the "slot setting" checkbox next to each of those to make sure it is a slot-specific setting that doesn't carry over when you swap.

Overall not the smoothest experience, and certainly prone to issues if functions are added or renamed. Would be nice if there was just a single application setting by convention that disabled all functions.

If I have a function app using mostly timer and queue triggered functions, should I even be using staging slots for my deployments? I don't want my functions in the staging slot competing for timer trigger locks and queue message locks with my actual production code.

[oatsoda]

I agree with @crowbarsolutions . I don't want to have to keep my deployment ARM Template up to date with a list of all of the Functions just to make sure the staging slots are always disabled.

[oatsoda]

Presumably the benefit of slots for Timer and Queue triggered functions is the "shutdown time".

So when you swap and production becomes staging, any currently executing Queue or Timer functions will be able to complete in their own time.

If you don't use slots I don't think you can guarantee this?

I've previously called Stop on my Function App before deploying to try and avoid file locking issues - but I understand that the grace time given to allow it stop is limited (is it 30 seconds? I can't find documentation at the moment). I know this is where the CancellationToken can be used to detect stopping - but that is entirely dependant on whether the business logic has the ability to exit and recover.

It would be really useful if someone from the Functions team could clear this up around Timer and Queue functions.

[pilgren]

I found this post while also looking into this issue.
In the bottom he shows the Disabled attribute that can be added to the classes containing your functions.
You will need to add a slot setting to set that your deployment slot is disabled and the production slot is enabled.
When doing this there is no need to stop the function or have all the function names in the ARM template.
I have just added this to our ARM templates and done a test and it works like a charm.

[varbanov88]

I use the same approach but the disable attribute is still not working on slot. Is there any other workaround or way to disable functions on slot programmatically?

[pilgren]

@varbanov88 have you set the slot setting named on the attribute to 0 on the production slot and 1 on the staging slot?
I also set the WEBJOBS_STOPPED. I'm not sure if that does anything for the functions, but with these two settings set I have a working production slot and a disabled staging slot.

[varbanov88]

@pilgren I used True and False (which was not working) and changed it to 0 and 1 and it is working now. Thank you

[nbgyxi]

In my opinion, all functions that are triggered automatically, like timer and queue, should be disabled by default, in the deployment slot.

I think it is quite common to use deployment slots like this:

1. Deploy to deployment slot
2. Warm up
3. Swap with production

That brings your new and bug free code to production. Great.

You don't want your buggy code still running in the deployment slot, causing errors that you thought you already solved.

[elliotchaim]

I agree that disabling all the functions in a slot should be possible via app settings.

[qcnguyen]

Please provide this feature, team.

[DarinMacRae]

$FunctionAppName = '<function_name>'
$ResourceGroupName = '<res_group>'
$Slot = "<slot>"

# uses https://github.com/Azure/azure-functions-core-tools
$Response = func azure functionapp list-functions $FunctionAppName --slot $Slot

$ParseTemplate = @'
{Name*:SomeApi} - {Trigger:[httpTrigger]}
{Name*:SomeQueueHandler} - {Trigger:[queueTrigger]}
'@

$Functions = $Response | ConvertFrom-String -TemplateContent $ParseTemplate

foreach ($name in $Functions.Name)
{
    Write-Host "Disabling" $name "in" $Slot "slot"
    $null = az functionapp config appsettings set --name $FunctionAppName --resource-group $ResourceGroupName --slot $Slot --slot-settings "AzureWebJobs.$name.Disabled=1"
}

HTH

[Oldrich-Vlasic]

Any updates on this?

[ttjackott]

In my opinion, all functions that are triggered automatically, like timer and queue, should be disabled by default, in the deployment slot.

I think it is quite common to use deployment slots like this:

1. Deploy to deployment slot

2. Warm up

3. Swap with production

That brings your new and bug free code to production. Great.

You don't want your buggy code still running in the deployment slot, causing errors that you thought you already solved.

100% this - we use it this way and have just noticed errors because of old code hanging around in the deployment slot.

Where is this feature?

[Recio]

Also wondering if this is planned in the near future 👍

Would be super handy to have!

[andrew-tevent]

@pilgren The workaround with the Disable attribute - how are you deploying your Sticky Slot Setting?

I don't quite understand how you can deploy this with ARM without causing a reload of the Production slot - or the fact that you have to deploy App Settings updates to the Production slot. I thought the whole point was deployment should update the settings in the Staging Slot, update the App in the Staging Slot and then finally swap in for no downtime...

[andrew-tevent]

Oh, and joy also because I'm trying to do this in new .net5.0 Isolated Process functions - and they haven't taken the Disable attribute across https://github.com/Azure/azure-functions-dotnet-worker/issues/312

[pilgren]

@andrew-tevent when using ARM templates to deploy the app settings you need to specify slotconfignames for the app settings that you want to be slot specific. You can see a short explanation here here
I guess that this might not be a viable solution for you if the new worker does not support it 😄

Yes, updating the regular app settings will cause the app to restart. If you frequently run into problems with this, I would suggest that you look into Azure App Configuration instead of using the app settings for all your settings.