Wrong plan after the first provisioning of an Open Telemetry plugin

[andrea-migliaccio]

Hi, it's me again :-)

After provisioning an OpenTelemetry plugin, a subsequent terraform plan shows several changes in the resource even if I haven't made any actual change to the resource definition.

This is just anoying because tf doesn't actually apply anything in reality. So, I'm not blocked by this issue.

Here's the plan

Here's the apply after confirming

[andrea-migliaccio]

@mheap and this error is popping up again during a tf plan :-( That's even stranger becase it wasn't appening few days ago.

[mheap]

That is strange! I'll take a look early next week

[andrea-migliaccio]

Hi @mheap I may have found what's is causing the issue.

As you may see from the error the provider isn't capable of unmarshalling the "headers" config property. What I've seen is that the OpenTelemetry instance that is causing the issue has

headers: [] // empty array

while others have

headers: null

I've provisioned all of them in the same way but maybe, someone has edited the first one and after that, the null became an empty array. To support this I tried to edit one of the other OT (just saving without changing anything from the edit mask) pluging and I can confirm that the headers property is now and empty array. The same happens to the "Resource Attributes" property.

Now, in order to if I need to manually delete the OT plugins from the portal and from the TF state as well and make TF provision them again.

After provioning it via TF

After editing the OT plugin from the Kong Konnect portal

[andrea-migliaccio]

I can confirm that this procedure (manually delete OT from kong interface and from TF state) has let me proceed, for now.

[mheap]

Thank you for the reproduction steps @andrea-migliaccio - I'll get to this in the next week or two

[mheap]

I've just reproduced. The schema marks this field as an object with additionalProperties: true which means the Go code is doing the correct thing by not deserializing. I'm investigating why the field is being set to [] by the UI

[mheap]

This is with an internal team to fix in the API itself. Thanks for raising the issue

[mheap]

@andrea-migliaccio Good news! I've just tested and this seems to be resolved. Thank you for bringing it to our attention

[andrea-migliaccio]

Hi @mheap is this fixing the error due to manual update of the plugin via UI, right? I trust you. I'd need to setup a temporary Control plane to test it :-)

Unfortunatelly within this issue we mixed-up to problems. The "phantom" plans (that I'm still experiencing) are still there (see the original issue post).