I tried to provision a device with the following parameters:
forProvider:
userdata: |
...
customdata: |
...
This failed to provision and I spent a while scratching my head wondering if the client was wired up correctly.
I did not receive an error when updating the resource to include this parameter, but it was eventually removed in a subsequent reconciliation.
I discovered that customData was the name that was correct and accepted.
It is confusing that userdata and customData do not follow the same standard.
Pick one.
Without knowing why the wrong case was accepted and later removed from the resource, users may attempt to use userdata or userData (similar for customdata) and experience the same problem. Should this change have been rejected earlier?
What happened?
I tried to provision a device with the following parameters:
This failed to provision and I spent a while scratching my head wondering if the client was wired up correctly. I did not receive an error when updating the resource to include this parameter, but it was eventually removed in a subsequent reconciliation.
I discovered that
customData
was the name that was correct and accepted.It is confusing that
userdata
andcustomData
do not follow the same standard.Pick one.
Without knowing why the wrong case was accepted and later removed from the resource, users may attempt to use
userdata
oruserData
(similar for customdata) and experience the same problem. Should this change have been rejected earlier?How can we reproduce it?
Use
customdata
in a device spec.What environment did it happen in?
Crossplane version: v0.14 EM Provider: v0.0.5