rhythmic-finland-3625610/17/2019, 3:22 PM
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
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?
will create an additional cluster as there is no more reference in the pulumi state…
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.
rhythmic-finland-3625610/17/2019, 5:04 PM
Resources: - 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
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-3625610/18/2019, 7:54 AM
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 ├── @email@example.com ├── @firstname.lastname@example.org ├── @email@example.com ├── @firstname.lastname@example.org ├── @email@example.com └── @firstname.lastname@example.org
context that pointed to a different azure tenant… 😠 The
was created in a different tenant hence could not be referenced by the
. It was caused by the
provider which was extracted into an own module and no longer used the
, … 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/p1567452303172900
module or do I need to configure the Azure provider twice in
[tenantId, subscriptionId, clientId, clientSecret, location, environment]
better-rainbow-1454910/21/2019, 4:38 PM
broad-dog-2246310/21/2019, 4:54 PM
rhythmic-finland-3625610/21/2019, 4:54 PM
module using my cli credentials…
broad-dog-2246310/21/2019, 5:06 PM
better-rainbow-1454910/21/2019, 5:37 PM
rhythmic-finland-3625610/21/2019, 6:56 PM
configs - but somehow missed that the
module uses different config properties. I would definitely vote for a
to avoid such dangerous scenarios.
disable ALL default providers
rhythmic-finland-3625610/22/2019, 12:49 PM