Skip to content
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

Retry "AnotherOperationInProgress" error messages #903

Open
sam-cogan opened this issue Jun 7, 2021 · 11 comments
Open

Retry "AnotherOperationInProgress" error messages #903

sam-cogan opened this issue Jun 7, 2021 · 11 comments
Labels
impact/reliability Something that feels unreliable or flaky kind/enhancement Improvements or new features size/M Estimated effort to complete (up to 5 days).

Comments

@sam-cogan
Copy link

Affected feature

Currently if Azure generates a "AnotherOperationInProgress" error Pulumi will fail. This error is often caused by trying to access two sub-resources on a resource at the same time. A good example is creating multiple subnets on a virtual network. Pulumi will try and create them all that the same time, but Azure can only create them one at a time.

Adding a back-off and retry for the "AnotherOperationInProgress" error message would help workaround this problem

@sam-cogan sam-cogan added the kind/enhancement Improvements or new features label Jun 7, 2021
@infin8x infin8x added kind/bug Some behavior is incorrect or out of spec and removed kind/enhancement Improvements or new features labels Jun 8, 2021
@infin8x
Copy link
Contributor

infin8x commented Jun 8, 2021

@sam-cogan we'll take a look at this. In the meantime, if you create a dependsOn chain with these sub-resources, Pulumi won't try to create them all at the same time. See https://www.pulumi.com/docs/intro/concepts/resources/#dependson for details.

@sam-cogan
Copy link
Author

@infin8x thanks, I have done that and it does indeed work around the issue.

@masashi-shib
Copy link

@sam-cogan we'll take a look at this. In the meantime, if you create a dependsOn chain with these sub-resources, Pulumi won't try to create them all at the same time. See https://www.pulumi.com/docs/intro/concepts/resources/#dependson for details.

While this workaround works perfectly the chaining of dependencies forces the developer to create the whole VNET and its Subnets in one module which is not optimal especially when trying to split code into different modules.

One example might be that the code for a specific module should create the Subnet in the VNET add the corresponding resources and configure firewall rules.

@masashi-shib
Copy link

@mikhailshilkov @infin8x I would also love to hear what is the impact of deleting the first subnet only (e.g. replacing its name) after the chaining is done.

e.g.
Subnet 1 <--depends_on-- Subnet2 <--depends_on-- Subnet 3

What happens if in the case the Subnet 1 name has been changed?
Does it create a havox delete basically on all resources that have an assignment in any of the subnets?

@mikhailshilkov
Copy link
Member

Does it create a havox delete basically on all resources that have an assignment in any of the subnets?

I think the answer is yes, unfortunately. In that case you'd have to remove all the dependsOn annotations and run an update before trying to rename the first subnet. I realise it's not ideal and we should solve the original problem.

@mikhailshilkov mikhailshilkov removed their assignment Nov 15, 2021
@deepak-goel
Copy link

Hi team, are there any plans to fix this? Terraform also had the same kind of race condition, but they already fixed that a while back.

@MatthewBettonMaif
Copy link

Hello Team,
We are having exactly the same problem and we have to remove our factorization in order to chain the creation of the subnets in same vNet by the code :/

@DSTAlan
Copy link

DSTAlan commented Apr 26, 2022

I'm also running into this issue so a fix would be great,
Thanks

Alan

@RockyMM
Copy link

RockyMM commented Oct 28, 2022

We just noticed this problem. If you need any help with this, I am more that willing!

@mikhailshilkov mikhailshilkov added kind/enhancement Improvements or new features impact/reliability Something that feels unreliable or flaky and removed kind/bug Some behavior is incorrect or out of spec labels Dec 20, 2022
@olafurnielsen
Copy link

Any updates on this issue? It's really unfortunate to have this awkward limitation, especially when Pulumi is being deployed via CI/CD and I don't feel like chaning depends is a viable option.

@RDavis3000
Copy link

RDavis3000 commented May 14, 2024

I'm getting it when trying to deploy a webapp. It deployed the rest of the stack ok, but keeps failing on this webapp, even though its the ONLY thing being deployed! I've waited 10-15 minutes from the first attempt.

its my first time using Pulumi so possibly I am doing something wrong:

// Create FunctionApp with Application Insights 
var functionApp = new WebApp(functionAppName, new WebAppArgs
{
    ResourceGroupName = resourceGroup.Name,
    ServerFarmId = appServicePlan.Id,
    SiteConfig = new SiteConfigArgs
    {
        AppSettings = new[]
        {
                new NameValuePairArgs { Name = "APPINSIGHTS_INSTRUMENTATIONKEY", Value = appInsights.InstrumentationKey },
                new NameValuePairArgs { Name = "WEBSITE_RUN_FROM_PACKAGE", Value = @"1" },
                new NameValuePairArgs { Name = "FUNCTIONS_WORKER_RUNTIME", Value = "dotnet" },
        },
        AlwaysOn = true,
    },
    Identity = new ManagedServiceIdentityArgs { Type = ManagedServiceIdentityType.SystemAssigned }
}, new CustomResourceOptions()
{
    DependsOn = new InputList<Pulumi.Resource>() { appInsights, imageStorageAccount, storageAccount, appServicePlan, blobContainer }
});

getting:

 Type                        Name         Status                  Info
 pulumi:pulumi:Stack         BandLab-dev  **failed**              1 error
  • └─ azure-native:web:WebApp functionApp creating failed 1 error
    Diagnostics:
    pulumi:pulumi:Stack (BandLab-dev):
    error: update failed

azure-native:web:WebApp (functionApp):
error: autorest/azure: Service returned an error. Status= . Cannot modify this site because another operation is in progress. Details: Id: 763f49a6-6c9d-474b-8308-5b47e4df80fb, OperationName: Create, CreatedTime: 5/14/2024 9:08:39 PM, RequestId: 71a73020-cef3-475a-89ed-c7af7e177931, EntityType: 3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
impact/reliability Something that feels unreliable or flaky kind/enhancement Improvements or new features size/M Estimated effort to complete (up to 5 days).
Projects
None yet
Development

No branches or pull requests

10 participants