Kong / terraform-provider-konnect

16 stars 3 forks source link

Wrong plan after the first provisioning of an Open Telemetry plugin #29

Open andrea-migliaccio opened 2 weeks ago

andrea-migliaccio commented 2 weeks ago

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

image

Here's the apply after confirming

image

andrea-migliaccio commented 1 week ago

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

image

mheap commented 1 week ago

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

andrea-migliaccio commented 1 week ago

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 image

After editing the OT plugin from the Kong Konnect portal image

andrea-migliaccio commented 1 week ago

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

mheap commented 6 days ago

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

mheap commented 6 days ago

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