neuspaces / terraform-provider-system Goto Github PK

When importing a file the plan do not show a diff of the file but only what will be pushed

To ease starting usage of the module, import should show a diff.
To get around it, I'm copying the actual file, applying the plan and run diff on the 2 files to make sure I did not broke something.

a similar solution is available in a similar existing provider: https://registry.terraform.io/providers/TelkomIndonesia/linux/latest/docs#provider-override

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.

It seems that service and timer are almost the same. Currently I'm using ansible provider to manage timers, but ansible is not capable of displaying changes only when there is a change to make.

Changing a file content make it delete/creating the resource. To me this should be done with an update of the resource.

I think it can even be harmful depending on what is using the file in the system to see it disappearing,

I already had one case that is harmful: handling the sudoers file with terraform-provider-system, make it losing right to sudo.

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If an issue is assigned to a user, that user is claiming responsibility for the issue.

Description

New or Affected Resource(s)

• system_service_systemd

For now, the resource system_service_systemd only able to manage the systemd unit type of .service, there are many other type of systemd unit might able to be manged by this resources, e.g. systemd unit type of .mount, .path, I think this resource should also able to manage them.

Please consider include these kinds of the unit type in system_service_systemd, or just remove the hard code of .service in the following
code of fmt.Sprintf in this file internal/client/service_systemd.go

Potential Terraform Configuration

# Propose what you think the configuration to take advantage of this feature should look like.
# Consider multiple alternatives for a discussion
# We may not use it verbatim, but it's helpful in understanding your intent.

References

• #0000