ibm_cos_bucket_object_lock_configuration implementation or documentation

[shemau]

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 CLI and Terraform IBM Provider Version

These comments are based on terraform 1.5.7 with terraform IBM Provider 1.64.1

Affected Resource(s)

• ibm_cos_bucket_object_lock_configuration

Expected Behavior

The terminology and content of the documentation is inconsistent with terraform.

These comments are about the resource argument reference and attribute reference of the documentation.

`object_lock_configuration` is a required object, not a required list. Only one block is supported and it is not a list. 
- Note: This is stored as a list of one object in the state file, so this may be a provider implementation issue rather than a documentation issue.

`object_lock_rule` is a required object, not a required list. Only one block is supported and it is not a list. 
- Note: This is stored as a list of one object in the state file, so this may be a provider implementation issue rather than a documentation issue.

`object_lock_enabled` can only have the value "Enabled".
- Many issues
  - If there is only one value, it does not need to be exposed. It could be handled in the provider.
  - If there are other values, that can not be set. It could be handled as a reference (rather than argument).
  - As implemented it is a required argument and must be specified, which is detected during plan. The plan does not validate the value, so it only fails during apply. It should fail at plan.

`mode` can only have the value "COMPLIANCE".
- All the same issues as `object_lock_enabled`. Should it ever be exposed?

`days` and `years` are mutually exclusive. Only one can be provided, the other should be null (or not coded). The validation would be far simpler for consumers, if the value `0` was treated as null, this permitting days=90,years=0 or years=1,days=0 both of which currently fail with error that only one can provided.

The attribute reference `crn` is not available. If it were to be made available, it should not be the bucket CRN, it should be a object lock configuration CRN (if such a thing exists).
The attribute reference `id` is available. This just seems to be the CRN with a different name, another reference to the bucket that was not created by this resource.

Important Factoids

References

• #0000

[IBM-diksha]

@shemau We are looking it and will get back to you on this one.