Can't delete monitor (In-Use)

[stobias123]

This one is tricky...

When trying to delete a monitor... The provider needs to remove from a pool before deleting. Otherwise we get this error.

Error: HTTP 400 :: {"code":400,"message":"01070083:3: Monitor /Common/monitor_default_pool is in use.","errorStack":[],"apiError":3}

Example before config.

resource "bigip_ltm_monitor" "example_health_check" {
  name     = "/Common/terraform_monitor"
  parent   = "/Common/http"
  send     = "GET /some/path\r\n"
  timeout  = "999"
  interval = "998"
}

resource "bigip_ltm_pool" "pool" {
  name                = "/Common/foo_pool"
  load_balancing_mode = "round-robin"
  description         = "portal"

  monitors            = ["${bigip_ltm_monitor.example_health_check}"]
  allow_snat = "yes"
  allow_nat  = "yes"
}

After.

resource "bigip_ltm_pool" "pool" {
  name                = "/Common/foo_pool"
  load_balancing_mode = "round-robin"
  description         = "portal"

  monitors            = [""]
  allow_snat = "yes"
  allow_nat  = "yes"
}

Do I have to finagle some kind of terraform lifecycle event to make this happen?

[papineni87]

This is the current behaviour in bigip, where when a monitor is attached to a pool and if you want to delete the monitor alone, we have to first detach monitor from pool and then delete the monitor.

So for the terraform also if you want to remove monitors alone, we have to first detach monitors from pool

monitors = [" " ] . with monitor resource intact in the config file [ " don't remove monitor resource ]

Now terraform apply, to remove monitor connection from pool.

Next we can remove monitor as we had removed the connection to pool and terraform apply to reflect it.

[stobias123]

I understand this is how the bigip works, but this takes away from the declarative ideology of terraform.

Take EIP attachments for example. They make sure to remove the EIP From the ec2 instance before deleting the resource. This hides the complexity from the user and lets the provider do the heavy lifting.

Is this type of process possible in bigip?

https://github.com/terraform-providers/terraform-provider-aws/blob/master/aws/resource_aws_eip.go#L379

[papineni87]

we didn't see any "isinstance" attribute for monitor to track the attachments to it when we did a GET request on monitors, but we will try any other alternative approach to handle it

[stobias123]

I have some ideas on how to implement this, but I'm not sure what version of the upstream go package I should be using...

Development seems to be going on here -> https://github.com/scottdware/go-bigip

But not in the f5devcentral package that's vendored...

Where do contributions to the underlying go sdk need to be made?

[dannyk81]

f5devcentral go-bigip is the one this project is based on, it was forked a while abck and diverged quite a bit, but it's the place for this provider.

[stobias123]

any reason not to merge some of the code back from scottdware? f5devcentral is largely missing any kind of testing and validation.

[dannyk81]

no argument on that from my end, but I can't really provide the background why it was necessary to fork the original project which is still under active development, surely if some functionality is missing - contributions will be accepted (though we may miss some context).

it is also very difficult to work with this (f5devcentral/go-bigip) fork, issues are not allowed so it's impossible to track/follow-up, there are no releases so vendoring is also tricky.

There's an open issue on that (https://github.com/terraform-providers/terraform-provider-bigip/issues/89) where I requested to formalize the work around this library but didn't get any updates recently.

Maybe one of the maintainers can shed more light on this.

/cc @scshitole @papineni87 @RavinderReddyF5 @GaddamSaketha

[ramganesh19]

Wow... Any update on this issue its been open for more than a year

[MasakariDOR]

I have this same issue with deleting monitors or persistence profiles. For example, swapping from one monitor type to another causes a deletion first. Using the lifecycle "create_before_destroy" stanza only affects that resource, not the dependencies so doesn't solve this issue.

[KrithikaChidambaram]

Hi, closing this request now. Please re-open if required or send an email to [email protected]. Thanks!