You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When repro'ing #69 (comment) and successfully completing cluster replacement after adding more subnets, destroying the cluster results in the same errors as #69 for all of the rules belonging to and including the nodeSecurityGroup.
The cause is tied to defaulting the ingress and egress rules to [] during the update that replaces the cluster, which never ends up recreating the secgroup rules. Then on the destroy, when the stand-alone secgroup rules resources are attempted to be deleted, because the rules were already removed / null'd out from the secgroup, we're returned the rule does not exist in the security group errors.
The null default for ingress & egress was intro'd in #109 as a requirement to be able to successfully update the cluster from using in-line secgroup rules to standalone rules.
The text was updated successfully, but these errors were encountered:
- Note: This PR reverses the default null values used for the
ingress and egress in-line rules of the secgroups, introduced in `v0.18.3`.
The null default was required to move to standalone secgroup rules, but it
has introduced [issues](pulumi#127), and thus is being removed in this PR.
- Upgrade path:
- If using >= `v0.18.3`: update using the typical package update path.
- If using <= `v0.18.2`:
1. First, update your cluster from using your current version to `v0.18.4`.
1. Next, update your cluster from `v0.18.4` to `v0.18.5` (or higher) using the typical package update path.
When repro'ing #69 (comment) and successfully completing cluster replacement after adding more subnets, destroying the cluster results in the same errors as #69 for all of the rules belonging to and including the
nodeSecurityGroup
.The cause is tied to defaulting the ingress and egress rules to
[]
during the update that replaces the cluster, which never ends up recreating the secgroup rules. Then on the destroy, when the stand-alone secgroup rules resources are attempted to be deleted, because the rules were already removed / null'd out from the secgroup, we're returned therule does not exist in the security group
errors.The null default for ingress & egress was intro'd in #109 as a requirement to be able to successfully update the cluster from using in-line secgroup rules to standalone rules.
The text was updated successfully, but these errors were encountered: