New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is there a way to disable all functions in a deployment slot? #2412
Comments
For 1.x runtime disabling functions for a slot is not achievable. https://docs.microsoft.com/en-us/azure/azure-functions/functions-versions |
@xt0rted - Closing this issue. Please reactivate if disabling each function in a slot does not work for your scenario. |
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? |
I will keep this issue open to track adding a setting to disable/enable all functions in a given slot. |
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. |
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. |
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 It would be really useful if someone from the Functions team could clear this up around Timer and Queue functions. |
I found this post while also looking into this issue. |
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? |
@varbanov88 have you set the slot setting named on the attribute to |
@pilgren I used True and False (which was not working) and changed it to 0 and 1 and it is working now. Thank you |
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:
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. |
I agree that disabling all the functions in a slot should be possible via app settings. |
Please provide this feature, team. |
$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 |
Any updates on this? |
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? |
Also wondering if this is planned in the near future 👍 Would be super handy to have! |
@pilgren The workaround with the 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... |
Oh, and joy also because I'm trying to do this in new .net5.0 Isolated Process functions - and they haven't taken the |
@andrew-tevent when using ARM templates to deploy the app settings you need to specify 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. |
Any update on this? |
I use a durable function. Should I add [Disable("IS_DISABLED")] for all the functions? |
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
to1
in the staging slots but that didn't seem to do anything for my functions app.The text was updated successfully, but these errors were encountered: