Implement the --exclude-protected feature #8359
Conversation
This piggybacks on the same machinery used by the --target flag. By examining the stack, we find a list of all resources managed by Pulumi (in that stack). We then form them into a DAG, and mark all resources as either protected or unprotected. A resource is protected it has the `Protect` flag set or is has a child with the `protect` flag set. It is unprotected otherwise. We then pass the urns of unprotected resources to the update options passed to the destroy operation in the same way that `--target` does.
Do we also treat resources that are dependencies of protected resources as protected? It feels like we'll need to, as we can't destroy those resources w/o first destroying the protected resources. |
We currently allow destroying dependencies of protected resources (we don't mark them as protected). My understanding was that dependencies encode only the data necessary to create a resource. I investigated after your comment, and found that this created some errors with invalid snapshots. I will rectify this to protect dependencies of protected products. |
pkg/cmd/pulumi/destroy.go
Outdated
| } | ||
|
|
||
| if targets != nil && len(*targets) > 0 && excludeProtected { | ||
| return result.FromError(errors.New("You cannot specify --target and --exclude-protected")) |
There was a problem hiding this comment.
Cannot specify it "yet"? Is there a fundamental problem here?
There was a problem hiding this comment.
--exclude-protected means destroy everything that is not protected. --target means destroy this specific thing. Any flag specified by --target would either be invalid (because it is protected) or would already be targeted by the destroy.
Because these flag behaviors don't make sense together, I forbid specifying both of them.
|
This is awesome! This is an awesome feature. I've just recently been proofreading some PRs around dependency handling and bugs in dependency handling and being quite confused. I'd like to work together to make this as explicit as possible. One PR I'd like to get merged before is: Then just like in 8360, I think we can possibly exploit DependencyGraph to encapsulate ordering assumptions as well as topsort and most importantly the definition of what do we mean by dependencies in there. DependencyGraph currently is build on this base relation: C child depends on P=C.Parent unless nil The transitive closure of the relation gives the "indirect" dependency relation. "dg.DependenciesOf" and "dg.DependsOn" query these relations. Presumably here, we could:
|
Except --target has --target-dependents which presumably uses graph computation that could use restricting - that's what I was thinking, but when you put it this way it's probably not worth it, reasonable to prohibit. |
|
@t0yv0 I would be happy to work with you to ensure everything is clear.
I would like this to be true, but I don't think it is.
We shouldn't need to do this. The engine should be able to handle this. |
This piggybacks on the same machinery used by the --target flag. By
examining the stack, we find a list of all resources managed by
Pulumi (in that stack). We then form them into a DAG, and mark all
resources as either protected or unprotected.
A resource is protected it has the
Protectflag set, is has a childthat is protected or has a dependency that is protected. It is unprotected otherwise.
We then pass the urns of unprotected resources to the update options
passed to the destroy operation in the same way that
--targetdoes.Description
Fixes #6539
Checklist