This reverts #32 because the updated way (that's being reverted) doesn't converge on the first run. This has to do with the way that Chef is evaluating the attributes and with that ruby_block. The current way ends up changing the password, but all of the rest of the code after the admin password change still sees the old password. That ends up failing. Just to note, this is with AEM 5.6.1, but would presumably fail in other versions as well, as this is a Chef issue.
I did wrap the future calls to node[:aem][:author][:admin_password] with lazy evaluation. That doesn't really do anything at the moment, but it shouldn't hurt.
I'm going to continue to think about this to see if there's a better way to address, but the cookbook shouldn't depend on failing the first run, so this fixes that issue for now.
@tmaier I'd be curious if you have any input into this, as you added the existing code. I'm genuinely curious if you're having the same issue with the first Chef run failing here.
This reverts #32 because the updated way (that's being reverted) doesn't converge on the first run. This has to do with the way that Chef is evaluating the attributes and with that ruby_block. The current way ends up changing the password, but all of the rest of the code after the admin password change still sees the old password. That ends up failing. Just to note, this is with AEM 5.6.1, but would presumably fail in other versions as well, as this is a Chef issue.
I did wrap the future calls to
node[:aem][:author][:admin_password]with lazy evaluation. That doesn't really do anything at the moment, but it shouldn't hurt.I'm going to continue to think about this to see if there's a better way to address, but the cookbook shouldn't depend on failing the first run, so this fixes that issue for now.
@tmaier I'd be curious if you have any input into this, as you added the existing code. I'm genuinely curious if you're having the same issue with the first Chef run failing here.