Open zaro0508 opened 2 years ago
I believe that is expected because the previous saved state still holds the stack as deployed. This behavior is the same as CloudFormation, except that OrgFormation does not have drift detection.
Additionally to the proposed workaround, sometimes I would change a property that causes a no-op update or some description.
the behaviour, indeed, is as intended. what does make sense is to document the ForceDeploy flag. thanks!
Just a note that setting ForceDeploy: true
doesn’t seem to re-deploy a stack if the stack already exists.
I am pretty sure it does. do you have a repro of where it doesn't?
@zaro0508 , from my experience, it does trigger a stack redeploy. Your problem might be related to the resource provider not triggering the update or CloudFormation not seeing that the state has changed.
ok, you're right @eduardomourar there was no state change since the existing stack deployed (without error) but it did NOT configure the password policy. I thought a ForceDeploy would re-deploy no matter what. Maybe that's just a bad assumption by me since the property was not documented? The name itself (ForceDeploy
) seems to imply that it will do as I expected, no?
Yes, I guess you are right. One could assume that it means that it will be updated forcefully through the AWS API directly.
Subject of the issue
We have the following template to configure the AWS password policy on all our AWS accounts.
I manually deleted the baseline-password-policy stack from account X using the AWS console. When I re-run
orgf perform-task
this template does not get re-deployed to account X.Your environment
Expected behaviour
I would expect org-formation to re-deploy baseline-password-policy.
workaround: rob3c on slack told me about the undocumented
ForceDeploy: true
task property which did re-deploy the stack.Actual behaviour
stack was not re-deploy to AWS account.