aiven / terraform-provider-aiven

Aiven Terraform Provider
https://registry.terraform.io/providers/aiven/aiven/latest/docs
MIT License
126 stars 69 forks source link

All ip_filters deleted when applying #1622

Closed mverle50 closed 6 months ago

mverle50 commented 6 months ago

What happened?

All ip_filter in ip_filter_string are deleted when i apply my terraform

What did you expect to happen?

No deletion on ip_filter when i update my window_time, plan or anything else

What else do we need to know?

Terraform v1.7.3 Aiven Provider 4.14.0

Serpentiel commented 6 months ago

Hey, @mverle50! 👋

Thank you for reporting this!

Could you please share an example of the plan that you are seeing, and a resource where this happens?

mverle50 commented 6 months ago

Thanks for the fast answer !

The plan is trying to update maintenance_window (Cf. screen) image

And on Aiven event log we can see that: image

byashimov commented 6 months ago

Hey @mverle50. I'm sorry to hear that. Could you please share more details?

  1. did you have ip_filter or ip_filter_string, or ip_filter_object?
  2. do you know what values were in the state before apply?
  3. what are the values after apply?
  4. does it keeping removing it on every apply?
  5. so ip_filters are removed eventually even though they are in tf file, right?
mverle50 commented 6 months ago
  1. I have ip_filter_string
  2. before my state have:
    "ip_filter": [ # 5 Ips ] 
    "ip_filter_object": [],
  3. After apply:
    "ip_filter": [],
    "ip_filter_object": [],
    "ip_filter_string": [],
  4. I don't know if it's a every apply but i've try on a plan change, a maintenant_window change and the problems occurs at these time without mention it in the plan
  5. Yes they are in tf file

After a deletion the next plan of the workspace is not trying to add theses IPs

byashimov commented 6 months ago
  1. I have ip_filter_string
  2. before my state have:
"ip_filter": [ # 5 Ips ] 
"ip_filter_object": [],

That's weird, ip_filter in the state, while ip_filter_string should be there. Did you also switched from ip_filter to ip_filter_string with the version upgrade? @mverle50

mverle50 commented 6 months ago

Several months ago, we updated our module to move from ip_filter to ip_filter_string and since this update no apply on theses workspaces had been necessary because there was no change noticed in the plan . So it seems that these are the first apply following this update. However the error returns several times in a row on the same workspace by adding manually the ip_filters in the aiven console because it is impossible to add them via terraform

byashimov commented 6 months ago

So it was:

  1. ip_filter -> ip_filter_string, but state had ip_filter
  2. then upgrade to 4.14
  3. apply new maintenance window -> cleared ip_filters

Let me reproduce it. Technically serialization part is different from the plan output. When it goes to json, it detects "had ip_filter, now don't have it" -> removes. Fixing state file, hence renaming ip_filter to ip_filter_string should fix the issue.

I'll come back with the fix as soon as possible.

byashimov commented 6 months ago

Hey @mverle50. I tried several pre v4.14.0 (>4) versions and I always get diff in the output:

          ~ ip_filter                  = [
              - "0.0.0.0/0",
              - "10.20.0.0/16",
              - "192.168.178.0/24",
            ]
          ~ ip_filter_string           = [
              + "0.0.0.0/0",
              + "10.20.0.0/16",
              + "192.168.178.0/24",
            ]

This bug is very dangerous and I'm highly motivated to fix it. Could you probably remember what was the versions transition?

mverle50 commented 6 months ago

Hey @byashimov Version transition was probably v4.5.0, our module use latest version and the plan/apply was done on 27 June 2023

byashimov commented 6 months ago

Hey @mverle50 Unfortunately, I can't reproduce it. I've tried all listed version. Is there anything you probably can remember to add to the timeline?

mverle50 commented 6 months ago

Hey @byashimov I don't remember any other information, I will try to do some tests again and see if it is still relevant, I will gather as much information as possible.

MarcoGlauser commented 6 months ago

We might be running into the same issue but with ip_filter_object. It seems to reorder the objects from time to time and we get a lot of in place updates that shuffle them around. Sometimes even an otherwise completely empty plan will trigger this.

          ~ ip_filter_object {
              ~ description = "Google looker studio" -> "GCP compute static egress ip address"
              ~ network     = "..." -> "..."
            }
          ~ ip_filter_object {
              ~ description = "GCP compute static egress ip address" -> "Google looker studio"
              ~ network     = "..." -> "..."
            }
Serpentiel commented 6 months ago

Hey, @MarcoGlauser! 👋

Could you please confirm the version that you're currently running?

MarcoGlauser commented 6 months ago

Hi @Serpentiel, We're running 4.14.0

Serpentiel commented 6 months ago

Hey, folks! 👋

@mverle50, If it helps to figure out a way to reproduce things, you could sign-up for a new Aiven account to redeem the free $300 credits. Please let me know if you have any additional information that could be helpful for us to fix this 🙏.

@MarcoGlauser, could you please take a look at https://github.com/aiven/terraform-provider-aiven/issues/1107 to see if it's the same issue?

Thanks, y'all!

MarcoGlauser commented 6 months ago

@Serpentiel It's not the same issue as #1107, since it also occurs without changing the ip_filter_objects. It sometimes reorders them when a plan should be completely empty. I'm happy to open another ticket if that's more appropriate.

Serpentiel commented 6 months ago

Hey, @MarcoGlauser! 👋

Please, do that 🙏.

Serpentiel commented 6 months ago

Hey, @mverle50! 👋

This issue has been discussed with the affected people through other channels, and was confirmed to be a combination of multiple factors, but at the end, does not appears to be a bug in the provider.

I will close the issue now.