Refresh dynamic credentials in provider state using stack refresh

[rquitales]

This PR enables a separate Pulumi Stack to be initialized with the intention of it being able to refresh secrets that are stored in state. The Stack CR is updated to contain 2 additional fields:

• spec.prerequisites: a list of references to other Stack CRs that the current stack depends on. This ensures that the prerequisite stack is successfully run before this current stack is reconciled.
• spec.targets: is the URN of specific resources that the Stack should be targeting when refresh is run.

The controller logic is updated to handle these 2 fields, and run the necessary refresh commands. A new test is added to test this flow, along with 2 testdata stacks, run-rabbitmq and use-rabbitmq. This test creates a RabbitMQ container with specified ports and a password, and attempts to go through the flow of using stack refresh with a separate targetted Stack CR to verify dynamic credentials in state is updated.

There are 4 files of particular interest for review:

• Updating API fields
  • pkg/apis/pulumi/shared/stack_types.go
  • pkg/apis/pulumi/v1/stack_types.go
• Controller logic update
  • pkg/controller/stack/stack_controller.go
• Additional test
  • test/stale_state_test.go

Supersedes: #320 Fixes: #299

[kpitzen]

If I'm understanding this PR correctly, it seems like we're targeting this:

Support a mechanism to allow stack authors to selectively target specific URNs for update before running refresh. This is essentially the equivalent of running pulumi up -t as in the CLI workaround mentioned above. With this the credential refresh code could live within the pulumi program and leverage the pulumi sdk instead of in a hand-coded script.

From https://github.com/pulumi/pulumi-kubernetes-operator/issues/299 - is that correct?

[rquitales]

If I'm understanding this PR correctly, it seems like we're targeting this:

Support a mechanism to allow stack authors to selectively target specific URNs for update before running refresh. This is essentially the equivalent of running pulumi up -t as in the CLI workaround mentioned above. With this the credential refresh code could live within the pulumi program and leverage the pulumi sdk instead of in a hand-coded script.

From #299 - is that correct?

Yes, that is correct.