Resources should support a 'delete' action

[ljfranklin]

Use Case

I'm working on a terraform resource which includes an option to run terraform destroy via a 'put':

- put: terraform
  params:
    action: destroy

This action destroys the infrastructure, removes the state file from S3, and returns the current timestamp as the version. Prior to the destroy step the version is the last modified time of the state file.

Issue

The put action is followed by an implicit get. In the normal case, a get would return an error if that state file could not be found. However, the implicit get should no-op after a put destroys the state file. My current workaround is to use get_params to tell get to no-op:

- put: terraform
  params:
    action: destroy
  get_params:
    action: destroy

This works, but requiring the user to specify a duplicate get_params action is confusing / error-prone. I think this problem would also apply to other resources that could destroy things like the CloudFormation and bosh-deployment resources.

Updated Suggestion from @vito and @robdimsdale

Supporting a delete resource option in addition to get and put clearly describes the intent of the action and avoids hacky patterns around destructive put operations.

Original Suggestion

One possible fix could be allowing resource authors to disable the implicit get following a destructive put via a new out field:

{
  "version": { "last_modified": "2016-04-09T19:20:47Z" },
  "metadata": [],
  "disable_implicit_get": true
}

Thanks!

[concourse-bot]

Hi there!

We use Pivotal Tracker to provide visibility into what our team is working on. A story for this issue has been automatically created.

The current status is as follows:

• #118060317 Resources should support a 'delete' action

This comment, as well as the labels on the issue, will be automatically updated as the status in Tracker changes.

[robdimsdale]

There are multiple resource that need to solve this problem. I think the right way to solve this it is for concourse to support delete as a resource operation, similar to get and put.

That would map more obviously to the underlying operation, rather than relying on esoteric params in the put that likely would differ between resources.

[vito]

👍 to @robdimsdale - this feels more appropriate with a delete action. I don't like the idea of resources saying to not perform a get after a put. If you've produced something (the intent of put) you should be able to fetch it. Sometimes that means doing a no-op.

[robdimsdale]

@vito is a delete on the radar? Any stories to keep an eye on?

[vito]

kinda: https://www.pivotaltracker.com/story/show/91815814

[ljfranklin]

👍 to you both. A first-class delete option would be ideal, I re-worded the issue to reflect this.

[vito]

Consolidating into #362

[oppegard]

@vito Now that this issue is closed, where is the feature being tracked so I can follow along?

[vito]

#534 - messed up my link

On Thu, Jul 14, 2016, 12:28 PM Glenn Oppegard notifications@github.com
wrote:

@vito https://github.com/vito Now that this issue is closed, where is
the feature being tracked so I can follow along?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#362 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAAHWF77_39K5bmuliImp1wCukmiz9hRks5qVo3wgaJpZM4IDtiH
.