Consider changing the behaviour of imported labels #1959
Labels
kind/bug
Some behavior is incorrect or out of spec
Comments
VenelinMartinov
added
kind/bug
Merged
VenelinMartinov
added a commit
that referenced
this issue
Apr 26, 2024
fixes #1916 This patches the upstream handling of labels to import `labels` and `pulumiLabels` as well as `effectiveLabels`. Note we handle `defaultLabels` on the provider by removing them from the imported `labels`. This allows for storage buckets to be imported cleanly along with their labels. The upstream provider does not import these properties. [The TF GCP provider allows](https://www.hashicorp.com/blog/terraform-google-provider-adds-updates-to-default-labels) for non-managed labels on resources. this PR changes this in our provider - it will now import ALL labels and assume they are all managed in pulumi by default. Note that we still allow manually editing the inputs after importing. There is no way to fix #1916 without this though - we either have to assume the labels are managed by pulumi or none are. Note that I adopted the import machinery from pulumi/pulumi-aws#3859 I've opened #1959 as a possible follow-up if we decide to fix this behaviour for other resources. Implementation might be tricky. --------- Co-authored-by: Ian Wahbe <[email protected]>
|
If we were to enhance |
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What happened?
We can follow-up on #1916 and #1946.
Currently ~all resources in GCP, when imported will import the labels in
effectiveLabelsand not inlabels. This means that the labels are not controlled in pulumi - GCP useseffectiveLabelsas a way to not override non-managed labels.We should reconsider this behaviour. It's a feature added in terraform in https://www.hashicorp.com/blog/terraform-google-provider-adds-updates-to-default-labels as a way to not manage all labels on resources. The import behaviour is not significant in terraform as they do not really support the same workflows of importing resources into already existing code.
We do support that and users seem to use the resources that way - we can change the import behaviour to assume, by default that all labels are managed. This is the model we have for almost all resource properties, so labels likely should not be different.
In terms of implementation, the most straightforward is a patch. Unfortunately this will affect ~all resources in GCP, so not sure we can do that.
We might be able to do something in the middle with
TransformOutputsbut that does not give us access to the providerdefaultLabelsso will not allow us to fix that in imports. This might be fine though.Example
import a resource (not a bucket) with labels defined. Observe that the labels property is empty after import.
Output of
pulumi about.
Additional context
No response
Contributing
Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).
The text was updated successfully, but these errors were encountered: