The `tags` attribute on `scaleway_object_bucket` is inconsistent and slightly broken.

[rbarrois]

trafficstars

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

Terraform Version

Terraform v1.5.6
on linux_amd64
+ provider registry.terraform.io/scaleway/scaleway v2.27.0

Affected Resource(s)

• scaleway_object_bucket

Terraform Configuration Files

resource "scaleway_object_bucket" "bucket" {
  name = "whatever"
  tags = {
    "key": "value"
  }
} 

Expected Behavior

The tags should be defined as for other resources:

tags = ["tag1", "tag2"]

Moreover, the value shouldn't be mangled in the UI — I should see my whole tags.

Actual Behavior

Tags are configured as a map for this specific resource. Moreover, only the map's values are visible in the UI (in this example, only value instead of some combination of key:value).

[Codelax]

These are the tags based on the S3 API we implement for object storage. S3 have tags in a Key/Value format.

[rbarrois]

This might be the case; however, with the way they are currently implemented, I have a constant terraform diff: scaleway's backend drops the tags' keys, and seems to internally map key: value to value: value.

The safest way would be to adjust the provider's behaviour to expose a list of tags as its API, while converting them to whichever format is required by Scaleway's backend.

[Mia-Cross]

Hello @rbarrois,

I investigated the issue and the only way that I could recreate it is by modifying the tags with the console but you don't mention this, did you have the problem using only Terraform or did you modify the tags with the console ?

The console doesn't handle key:value tags yet so it will only display the values. But if you change the tags via Terraform or the s3 API, the tags stay in the key:value form, they are just not displayable in the console. However if you make any change to the tags via the console, it will send a PUT request that will overwrite them with the wrong format value:value.

[rbarrois]

@Mia-Cross I might have looked at the tags in the console indeed; I do not remember editing them, but I might have simply clicked "save" after opening the details.

Nevertheless, the lossy behaviour between the various endpoints is still an issue:

• The web console ignores anything before the column (foo:bar is the same as bar:bar or quux:bar from its point of view);
• The API uses the S3-style key:value format;
• The terraform resource sticks to the S3-style format ({key: value, ...}), whereas all other resources use a [value, ...] format.

Unless Scaleway plans to add a notion of key/value to their tags, I think the best courses of actions would be one of the following:

• Switch the terraform resource to tags = [value, ...], and internally map them to {value: value} when communicating with the S3 API;
• Or at least add an example snippet in the documentation explaining how to map a list of tags into the specific format for that resource.

[Mia-Cross]

To keep you updated about the issue, this behavior has been documented, and in the future the console will eventually add support to key:value tags. In the meantime, we did what we could on our end, but we prefer not to change the behavior temporarily, only to change it again when the feature is implemented in the console, as we believe this would be confusing for our users.

[rbarrois]

Thanks a lot for the clear feedback; I'm quite happy with the proposed course of action, as long as a more consistent option ends up being available!