rhythmic-finland-36256
10/17/2019, 3:22 PMpulumi destroy
on an AKS cluster with custom networking (referencing a self-created subnet from the aks cluster) resulted in an error of wrong destroy order (subnet cannot be deleted as there are resources in it) So pulumi lost the aks cluster from the pulumi state but it still exists in Azure. Adding a dependsOn
seems unnecessary as the chain should already exist due to the reference of the subnet in the aks cluster creation. How to clean that up? pulumi up
will create an additional cluster as there is no more reference in the pulumi state…pulumi destroy
once more resolved the issue. But I’m wondering how I can express this behaviour that deleting the aks cluster must be awaited before deleting the subnet.white-balloon-205
rhythmic-finland-36256
10/17/2019, 5:04 PMResources:
- 21 to delete
Do you want to perform this destroy? yes
Destroying (dev):
Type Name Status Info
pulumi:pulumi:Stack azure-infra-eval-dev **failed** 1 error
- ├─ pulumi:providers:kubernetes neo-azure-pulumi-eval-aks-provider deleted
- ├─ azure:containerservice:KubernetesCluster neo-pulumi-aks deleted
- ├─ azuread:index:ServicePrincipalPassword neo-azure-pulumi-eval-aks-sp-password deleted
- ├─ azure:role:Assignment neo-azure-pulumi-eval-acr-assignment deleted
- ├─ azuread:index:ServicePrincipalPassword neo-azure-pulumi-eval-acr-push-sp-password deleted
- ├─ azure:role:Assignment neo-azure-pulumi-eval-aks-network-assignment deleted
- ├─ azure:dns:ARecord dns-dummy-azureeval deleted
- ├─ azure:dns:ARecord dns-wildcard-azureeval deleted
- ├─ azure:role:Assignment neo-azure-pulumi-eval-acr-push-assignment deleted
- └─ azure:network:Subnet neo-azure-pulumi-eval-aks-subnet **deleting failed** 1 error
al-aks-subnet: Error deleting Subnet "neo-azure-pulumi-eval-aks-subnet96be16e1" (Virtual Network "neo-azure-pulumi-eval-aks-v
Diagnostics:
azure:network:Subnet (neo-azure-pulumi-eval-aks-subnet):
error: Plan apply failed: deleting urn:pulumi:dev::azure-infra-eval::azure:network/subnet:Subnet::neo-azure-pulumi-eval-aks-subnet: Error deleting Subnet "neo-azure-pulumi-eval-aks-subnet96be16e1" (Virtual Network "neo-azure-pulumi-eval-aks-vnet5012bfc3" / Resource Group "pulumi-azure-evalf9c2b004"): network.SubnetsClient#Delete: Failure sending request: StatusCode=400 -- Original Error: Code="InUseSubnetCannotBeDeleted" Message="Subnet neo-azure-pulumi-eval-aks-subnet96be16e1 is in use by /subscriptions/xxxxxxxx-xxxx-xxxx-b584-12e917417d0f/resourceGroups/MC_pulumi-azure-evalf9c2b004_neo-pulumi-aksb9e37d00_westeurope/providers/Microsoft.Network/networkInterfaces/aks-aksagentpool-28966608-nic-0/ipConfigurations/ipconfig1 and cannot be deleted. In order to delete the subnet, delete all the resources within the subnet. See <http://aka.ms/deletesubnet|aka.ms/deletesubnet>." Details=[]
pulumi:pulumi:Stack (azure-infra-eval-dev):
error: update failed
white-balloon-205
Basically the aks cluster was reported as deleted but I assume the real deletion takes way longer on azure and then when trying to delete the subnet this fails as there are still ips of the cluster nodes attached.That sounds like a bug in Azure or in the upstream Terraform Azure Provider then. I have definitely seen issues with Subnet deletion taking hours on Azure - and I know many of these have been fixed in the upstream provider. @broad-dog-22463 may be able to point at tracking issues or make sure there is one tracking this upstream if it is reproducible.
rhythmic-finland-36256
10/18/2019, 7:54 AMnpm install
and still observe the same strange issues that no `Application`s are created. This is pretty frustrating. Could this be caused by an update of the azure-cli?$ npm list --depth=0
azure-typescript@ /Users/ajaegle/dev/evals/pulumi-tests/azure-infra-eval
├── @pulumi/azure@0.19.5
├── @pulumi/azuread@0.18.4
├── @pulumi/kubernetes@0.25.6
├── @pulumi/pulumi@0.17.28
├── @pulumi/random@1.0.0
└── @types/node@12.11.1
azure-cli
context that pointed to a different azure tenant… 😠 The Application
was created in a different tenant hence could not be referenced by the Assignment
. It was caused by the azuread
provider which was extracted into an own module and no longer used the azure:tenantId
, azure:clientId
, … Of course that worked the whole time my pulumi programs targeted the same tenant as my cli. This mechanism is pure evil and russian roulette.
We definitely need a way to disable this default behaviour globally!
At least I expected this to happen… https://pulumi-community.slack.com/archives/C84L4E3N1/p1567452303172900azuread
module or do I need to configure the Azure provider twice in azure:xxx
and azuread:xxx
(for xxx
in [tenantId, subscriptionId, clientId, clientSecret, location, environment]
?better-rainbow-14549
10/21/2019, 4:38 PMbroad-dog-22463
10/21/2019, 4:54 PMrhythmic-finland-36256
10/21/2019, 4:54 PMazuread
module using my cli credentials…broad-dog-22463
10/21/2019, 5:06 PMwhite-balloon-205
better-rainbow-14549
10/21/2019, 5:37 PMrhythmic-finland-36256
10/21/2019, 6:56 PMazure:xxx
configs - but somehow missed that the azuread
module uses different config properties. I would definitely vote for a disable ALL default providers
to avoid such dangerous scenarios.white-balloon-205
rhythmic-finland-36256
10/22/2019, 12:49 PM