opentelekomcloud / terraform-provider-opentelekomcloud

Terraform OpenTelekomCloud provider
https://registry.terraform.io/providers/opentelekomcloud/opentelekomcloud/latest
Mozilla Public License 2.0
87 stars 78 forks source link

opentelekomcloud_ces_alarmrule not allowed to create alert rules where the metric_name starts with "/" for Linux mount points. #2078

Open thople opened 1 year ago

thople commented 1 year ago

Terraform provider version

Terraform v1.3.7

Affected Resource(s)

"opentelekomcloud_ces_alarmrule"

Terraform Configuration Files

resource "opentelekomcloud_ces_alarmrule" "disk_usage" { alarm_name = "alert-name" alarm_action_enabled = true metric { namespace = "SYS.ECS" metric_name = "/_disk_usedPercent" dimensions { name = "instance_id" value = data.opentelekomcloud_compute_instance_v2.instance.id } } condition { period = 1 filter = "sum" comparison_operator = ">=" value = 90 unit = "%" count = 3 } }

Debug Output/Panic Output

│ Error: invalid value for metric.0.metric_name (Must start with a letter.) │ │ with module.cloudeye-alert.opentelekomcloud_ces_alarmrule.disk_usage, │ on ../../../modules/main.tf line 87, in resource "opentelekomcloud_ces_alarmrule" "disk_usage": │ 87: metric_name = "/_disk_usedPercent" │

Steps to Reproduce

  1. 'create an alart rule with metric_name that starts with "/" like for example: metric_name = "/_disk_usedPercent" or metric_name = "/opt_disk_usedPercent"
  2. terraform apply

Expected Behavior

Should allow creating alartrule Terraform that starts with "/" for Linux mount points. Like this in the interface. (added manual in interface) screenshot alart policy

Actual Behavior

It forces creating alert rules that start with a letter. It will create the alert if you add a letter, but this won't work for Linux. Furthermore, it's written in the web interface behind the "?" at Mount point option to add it with "/": · For a Windows OS, enter a drive letter, such as C, D, or E. · For a Linux OS, enter a mount point, such as /dev or /opt.

anton-sidelnikov commented 1 year ago

@thople hi, please check on latest

thople commented 1 year ago

@anton-sidelnikov hi, thank you for the quick fix.

I tested but there is still a bug in it.

What happens is that it creates the alarm rule just as it should be, but it won't work. The only way to make it work is to manually go into the interface, modify it, and then save it again. For some reason, it then creates a second alert rule that is exactly the same in the interface, but this one works while the one created with Terraform doesn't.

anton-sidelnikov commented 1 year ago

@thople hm, seems another bug, will ask QA team

anton-sidelnikov commented 1 year ago

@thople could you show some pictures what exact not working in rule?

I created that in latest provider:

resource "opentelekomcloud_compute_instance_v2" "vm_1" {
  name        = "instance_1"
  image_name  = "Standard_Debian_11_latest"
  flavor_name = "s3.large.2"

  network {
    uuid = data.opentelekomcloud_vpc_subnet_v1.shared_subnet.network_id
  }
}

resource "opentelekomcloud_ces_alarmrule" "alarmrule_s" {
  alarm_name = "alarm_rule_s"

  metric {
    namespace   = "SYS.ECS"
    metric_name = "/mnt/share_disk_usedPercent"
    dimensions {
      name  = "instance_id"
      value = opentelekomcloud_compute_instance_v2.vm_1.id
    }
  }
  condition {
    period              = 1
    filter              = "sum"
    comparison_operator = ">="
    value               = 90
    unit                = "%%"
    count               = 3
  }
  alarm_action_enabled = false
}

image

thople commented 1 year ago

@anton-sidelnikov

What I did to test the alarm rule was creating an alarm rule for the EC2 instance, just as you can see in the Terraform code I shared. After that, I created a file that fills the disk on the "/" mount point (/_disk_usedPercent) above the 90% threshold. If you look in the Alarm Records, it should trigger an alarm like this, but this is not the case for Terraform created alarm rules. OTC ec2 alarm record

anton-sidelnikov commented 1 year ago

@thople Thank you, yes seems api works differently from UI, created internal issue for backend team: https://jira.tsi-dev.otc-service.com/browse/BM-1550