Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support override resource unconditionally #4

Open
n0rad opened this issue Jan 30, 2023 · 4 comments
Open

Support override resource unconditionally #4

n0rad opened this issue Jan 30, 2023 · 4 comments
Labels
enhancement New feature or request

Comments

@n0rad
Copy link

n0rad commented Jan 30, 2023

When declaring a resource that already exists, the provider fail with Error: file resource: file exists
It could be nice to have a way to make provider's resources override existing resources unconditionally since the provider can be considered as owner of those resource.

In the same manner, when a resource handle by the provider is deleted by something else, the terraform plan is failing because the resource is not found instead of planning to re-write the resource.

@n0rad n0rad added the enhancement New feature or request label Jan 30, 2023
@n0rad n0rad changed the title Support override resource inconditionally Support override resource unconditionally Jan 30, 2023
@StopDenBus
Copy link

Would be nice to have this feature, maybe as an "force-overwrite" option

@dominik-lekse
Copy link
Member

@n0rad Thanks for reporting this issue.

I agree that there are use cases in which an existing file must be extended.

The current behavior of the system_file resource complies with the convention of terraform to fail when a resource already exists. In this case, terraform advises an explicit import.

I am considering an implementation of a separate resource system_file_existant for the use case you reported. With the separate resource, the user must explicitly decide whether an existing file is expected. The resource would automatically import an existing file and revert the file to the original state when destroyed.

@n0rad
Copy link
Author

n0rad commented Nov 14, 2023

👋 I agree that the default behavior should be to fail if the resource already exists, like the convention of terraform.

For resources like files and folders, I think users can face more often modifications outside of terraform than usual other terraform resource and so to me the provider should strongly support it. I don't think you have to create another resource since like @StopDenBus said, a flag on the existing resource will probably be enough, but it's up to you.

To me users setting the flag to true make it explicilt that terraform must own the content, so I don't think you have to support being able to restore the content, but again it's up to you 🙂

@StopDenBus
Copy link

I agree with @n0rad. You don't need to create a new resource. Forcing overwrite content means "I know what i do and I have read the small print".
My use-case is to install and configure a service from scratch. Mostly you will get a default configuration and you need to overwrite it's content. Manually import a resource is not an option. At the moment, I'm using resource linux_file from TelkomIndonesia/linux, but it's missing the cool md5sum feature you have.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants