Request for Enhancement - Add functionality to ignore creation of resource if exists

[wninobla]

Hi,

So, I ran into the dreaded state issue with Terraform (I accidentally deleted the state files and the resulting apply command wouldn't let me delete stuff since it thought it was new). So... I was wondering is there a way to create infrastructure in that either:

1. It ignores resources already in the architecture based on an existing plan as opposed to relying on the initial terraform build (e.g. Support ignoring changes to a resource, if it already exists. hashicorp/terraform#2437)

2. Can we create a new script for scraping a target resource (network domain, firewall ACL's, etc.) where we can create a pescriptive state file and/or something that is exportable/importable? I see the Go script but for folks not working in that its not as easy.

Let me know what you think. Thanks!

[tintoy]

I'll have to think about this; Terraform isn't really meant to work like this (since the Ids for CloudControl entities are unique but other properties such as name may not be). Terraform v.07 introduced a new import facility we don't support yet but once we do I believe this will give you what you need.

For now, can I suggest using Amazon S3 or similar to store your Terraform state? It's not only harder to accidentally delete but also versioned so you can revert the state if it becomes broken.

[tintoy]

@wninobla, I've created a Milestone to track the progress of the state-import facility. I'll create issues under that to track the work on this as it happens (may be a little while before I get to it due to time and resource constraints, but it's totally doable).

[wninobla]

OK, yeah was raising it more of an issue. I can see people wanting to say photocopy or blueprint an existing environment and then using the resulting .tf/.plan file to execute a DR copy or the like. OI course we can have them do it by hand by providing a count function and just using the different sections with variables but not everyone is terraform snazzy like you... =)

On that note, I will leave this one open for now unless you think the updates will really take awhile. Let me know - thanks!

[tintoy]

If you are duplicating an existing environment then you'd share config (.tf) rather than state (.tfstate), no?

On 27 Sep. 2016, at 2:44 am, wninobla [email protected] wrote:

OK, yeah was raising it more of an issue. I can see people wanting to say photocopy or blueprint an existing environment and then using the resulting .tf/.plan file to execute a DR copy or the like. OI course we can have them do it by hand by providing a count function and just using the different sections with variables but not everyone is terraform snazzy like you... =)

On that note, I will leave this one open for now unless you think the updates will really take awhile. Let me know - thanks!

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[wninobla]

This one is for say an IT admin who wants to help suck his/her infrastructure into the cloud as part of an DR strategy just in case the office equipment dies. I'd say its more of a niche case but all the same an IT admin will use whatever is easiest to roll out their infrastructure whether its terraform or something else.

[tintoy]

Ok - yes the import facility should be able to handle that :)

On 27 Sep. 2016, at 6:05 am, wninobla [email protected] wrote:

This one is for say an IT admin who wants to help suck his/her infrastructure into the cloud as part of an DR strategy just in case the office equipment dies. I'd say its more of a niche case but all the same an IT admin will use whatever is easiest to roll out their infrastructure whether its terraform or something else.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[tintoy]

Tracked via #29.