3

Is there a way to create a resource if it doesn't exist and use an existing resource if it does?

resources:
  - name: "my-topic"
    type: gcp-types/pubsub-v1:projects.topics
    properties:
      topic: "this-exists-already"
  - name: "my-other-resource"
    type: 'gcp-types/cloudfunctions-v1:projects.locations.functions'
    properties:
      functionName: "function"
      environmentVariables:
        # get a ref to new or already existing topic
        my-toptic: "$(ref.my-topic.name)"

Per @kolban's link I think I want to use abandon here. Can I selectively "abandon" a specific resource so I can, for example, attach an accessControl policy to an existing bucket but then NOT delete that bucket if the deployment is deleted?

ABANDON - This removes any references to the resource from the deployment but does not delete the underlying resource. For example, abandoning an instance means that it is removed from a deployment but the instance still exists for you to use.

Edit

Maybe I should use an "action" to assign an acl instead of a resource? Is this the right way and are there examples of this? So DM would essentially just execute an api call to apply an acl out-of-band. That would mean it would leave the acl behind if the deployment is deleted but I'm okay with that.

It looks like I want to do something like this but instead of applying an acl to a specific file I want to set it on the bucket (with an action) https://github.com/GoogleCloudPlatform/deploymentmanager-samples/blob/master/community/storage-bucket-acl/storagebucket-acl.jinja#L29.

halfer
  • 19,824
  • 17
  • 99
  • 186
red888
  • 27,709
  • 55
  • 204
  • 392

1 Answers1

4

If we read this section of the Deployment Manager documentation:

https://cloud.google.com/deployment-manager/docs/deployments/updating-deployments#policies_for_adding_resources

We read about the concept of "create or acquire". The way I read this is that if a resource your configuration says should be created then the default appears to be that if it already exists, it will not cause an error and will be "acquired" for this deployment which I take to mean that it will be as though it had been created.

Kolban
  • 13,794
  • 3
  • 38
  • 60
  • 1
    Of course, note that the deployment goes on to "own" the resource in this case, and there is a note on that page that: "Warning: Do not acquire resources that are already part of another deployment. If you do, any changes you make to one deployment can cause unexpected behavior with the resources in the other deployment." – robsiemb Oct 15 '19 at 03:03
  • So if the deployment "acquires" an existing resource and then I delete that deployment is the resource also deleted? I only want to grab a reference to it not control its lifecycle. I could add my own conditional logic to the jinja templates- is there a macro to check if a resource exists without resorting to a scripted python "template" – red888 Oct 15 '19 at 03:52
  • 1
    My understanding is that the last deployment config run that attempts to "create" a resource becomes the "owner" of that resource. If you thus execute a delete on the deployment, then the resource that previously existed will also be deleted. I don't believe that there are any concepts such as "usage count" that would keep it consistent if there were overlapping deployments. If no such meta data exists, I can't see how even python would help. – Kolban Oct 15 '19 at 03:58
  • updated my question I think I want to selectively abandon a resource if this is possible – red888 Oct 22 '19 at 17:54