sdwan_sla_class_policy_object, fallback_best_tunnel_* items can be 0

[cmohorea]

It could be more of vManage problem but still:
"fallback_best_tunnel_jitter", "fallback_best_tunnel_latency", "fallback_best_tunnel_loss" parameters may be skipped during config.

When they are unused, in terraform they show up as 0 (unlike main parameters (loss, jitter, latency) which show up as null) which probably make sense in this case, since variance of 0 actually means that no variance in play.
However, 0 is not accepted in the terraform configuration (allowed range starts at 1), so they cannot be configured as "0"

Error: Invalid Attribute Value

  with sdwan_sla_class_policy_object.test_CN_SLA_DEFAULT,
  on sdwan-tf-import-main.tf line 15365, in resource "sdwan_sla_class_policy_object" "test_CN_SLA_DEFAULT":
15365:   fallback_best_tunnel_jitter = 0

Attribute fallback_best_tunnel_jitter value must be between 1 and 1000, got:
0

They can be set as "null" with terraform (but I am not sure what the actual vManage config would be, it could actually require 0 there) but after editing in GUI, they will be set to 0 and terraform would try to fix it on the next run:

Terraform will perform the following actions:

  # sdwan_sla_class_policy_object.test_CN_SLA_DEFAULT will be updated in-place
  ~ resource "sdwan_sla_class_policy_object" "test_CN_SLA_DEFAULT" {
      - fallback_best_tunnel_jitter   = 0 -> null
      - fallback_best_tunnel_loss     = 0 -> null

I believe that it should be allowed to be 0, and documented that 0 means it's not in use.

[cmohorea]

resource "sdwan_sla_class_policy_object" "test_CN_SLA_DEFAULT" {
  name = "test_CN_SLA_DEFAULT"
  fallback_best_tunnel_criteria = "loss-latency"
  fallback_best_tunnel_latency = 10
#  fallback_best_tunnel_jitter = null
#  fallback_best_tunnel_loss = null
  latency = 200
  loss = 10
}

config for the reference

[cmohorea]

Worked with SLA objects recently and this is still happening.
To reproduce:
1: Create SLA object:

---
sdwan:
  policy_objects:
    sla_classes:
      - name: slaTEST
        loss_percentage: 1
        jitter_ms: 100
        latency_ms: 150
        fallback_best_tunnel_criteria: loss

2: after creating it, go to vManage and edit the slaTEST object. Do not change anything, just click save
3: do terraform plan

Terraform will perform the following actions:

  # module.sdwan.sdwan_sla_class_policy_object.sla_class_policy_object["slaTEST"] will be updated in-place
  ~ resource "sdwan_sla_class_policy_object" "sla_class_policy_object" {
      - fallback_best_tunnel_jitter   = 0 -> null
      - fallback_best_tunnel_latency  = 0 -> null
      - fallback_best_tunnel_loss     = 0 -> null
        id                            = "81a72712-dc34-4fb9-acbb-cd0b521c0539"
        name                          = "slaTEST"
      ~ version                       = 0 -> (known after apply)
        # (4 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

Also if you set the value of jitter/latency/loss as "0", an error is thrown

[seconroy]

When loss variance, latency variance and jitter variance are unused in the GUI they are configured as null which is unusual as in most resources they are not included if unconfigured or have a default value. Unfortunately this means just allowing 0 wont fix this issue and will probably require an update to the toBody and fromBody functions to prevent this edge case from occurring.

{
    "name": "yesyegrkfgerfgwerf",
    "description": "Desc Not Required",
    "type": "sla",
    "entries": [
        {
            "latency": "12",
            "loss": "12",
            "jitter": "1",
            "fallbackBestTunnel": {
                "criteria": "loss-latency",
                "jitterVariance": null,
                "latencyVariance": null,
                "lossVariance": null
            }
        }
    ],
    "infoTag": ""
}

Also, jitter, latency, and loss don’t accept 0 as a value in the GUI and we try to align the provider to the GUI when no schema is available. If I am wrong or there is an option to enable this please let me know

[cmohorea]

it is fine to not allow 0 - that was extra troubleshooting info. null is accepted in YAML and seems to have the same effect as omitting the setting (expected, I guess)

I see that when template is created by TF, those 3 fields are missing, so I guess they are assumed to be null by vManage.... not sure how they become "0" when doing "terraform plan". I guess they should be always included in the TF's API payload and/or assumed Null vs 0 when missing... you know this better!