That's OK in itself, unless we need to add a lifecycle.ignore_changes on certain custom_attributes, which is at the current state of things, very user unfriendly - since variables can't be used in lifecycle blocks, one either has to put custom_attributes, or use the ID of the custom attribute as per VMware, which is hard to find, and impossible to use with modules used across different vCenters. The specific use case is that some third-party tools, like Veeam or Zerto vSphere backups leave specific custom attributes with information, which are seen by terraform, generate diffs, and are impossible to keep up with from within terraform ( they usually change at least daily, or whatever the frequency of backups is).
Ideally, we should be able to set custom_attributes based on their name as per the vCenter. I think that it's entirely doable to be able to search with the custom_attribute key provided first within IDs, then within names, and make the change regardless of if it's a name or id; of course, renaming the custom attribute vCenter-side will break the configuration, but considering in most cases people are using a data source by name to get the ID anyway, it stays the same case.
Potential Terraform Configuration
custom_attributes = map(
data.vsphere_custom_attribute.project.id, "web", # same as now
data.vsphere_custom_attribute.env.name, "prod", # name isn't currently exported but could be easily added
"role", "api" # using the name statically
)
lifecycle {
ignore_changes = [custom_attributes["role"]]
}
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 other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment
or specify that the map of custom attributes that you are providing should just be merged with what exists already so you don't stomp on attributes not managed in terraform.
Description
Currently, the provider manages custom attributes via their id, like so:
That's OK in itself, unless we need to add a lifecycle.ignore_changes on certain custom_attributes, which is at the current state of things, very user unfriendly - since variables can't be used in lifecycle blocks, one either has to put
custom_attributes
, or use the ID of the custom attribute as per VMware, which is hard to find, and impossible to use with modules used across different vCenters. The specific use case is that some third-party tools, like Veeam or Zerto vSphere backups leave specific custom attributes with information, which are seen by terraform, generate diffs, and are impossible to keep up with from within terraform ( they usually change at least daily, or whatever the frequency of backups is).Ideally, we should be able to set custom_attributes based on their name as per the vCenter. I think that it's entirely doable to be able to search with the custom_attribute key provided first within IDs, then within names, and make the change regardless of if it's a name or id; of course, renaming the custom attribute vCenter-side will break the configuration, but considering in most cases people are using a data source by name to get the ID anyway, it stays the same case.
Potential Terraform Configuration
Community Note