terraform-provider-bigip
terraform-provider-bigip copied to clipboard
Add bigip_ltm_policy_rule resource and removing rule list
Is your feature request related to a problem? Please describe.
When I have policies with many rules and a large number of variation of the rules (for example add/delete rules to policy frequently), each modification is a modification of the same resource. Error risk are high because policy resource code became hard to read/write and a code error can lead to invalidating the entire policy.
Describe the solution you'd like
I suggest to substitute rule list attribute in bigp_ltm_policy with a new resource bigip_ltm_policy_rule, likewise to ansible module
Additional context
I have a scenario with one policy and many (tens) rules (forward action based on match uri prefix) with several variation each week.
Hi,
Thank you for your feedback. We'll review it.
Hi,
Adding this change will introduce a breaking change so we prefer to keep the current resource.
Hi,
Adding this change will introduce a breaking change so we prefer to keep the current resource.
With two separate resources there are many advantages:
- resource configuration is easier
- when you execute a TF plan, output is more clear. Otherwise all actions (add/delete/modify a rule) are resourse are resource modification
- it' s easier create policy with IaC scan languages (for example checkov, kics,...)
With rest api and ansible module you can create the policy directly with its rules or creare an "empty" policy and add/modify/delete its rules separately.
TF provider is based on go sdk but currently it seems it doesn't support api rest to mangese rule object (see this examples) but only CreatePolicy and CreatePolicyDraft (link).
Unlike ansible module, I agree with you that with Terraform it's better to allow rule actions only on one resource type.
For these cases in other providers they proceed by creating two new resources, deprecating and removing the old one after a certain period of time.
Hi @marcoboffi,
Thank you for sharing your feedback with us. We appreciate your insights regarding the potential benefits of utilizing two resources. However, at present, we have received only one request for this modification. Our commitment is to ensure the highest level of support for all our customers. Therefore, we will carefully monitor any additional requests for this change in the future. Your input is valuable to us, and we will consider it in our ongoing efforts to enhance our services.
I second this change. While it would change the data format, I've been playing with this provider for a couple hours and I've already found a big issue.
When changing from
rule {
name = "asganaway"
condition { [...] }
action {
insert = true
connection = false
http_header = true
request = true
select = false
tm_name = "Whatever"
value = "asganaway"
}
action {
forward = true
connection = false
pool = bigip_ltm_pool.trnz0.name
}
}
to
rule {
name = "asganaway"
condition { [...] }
action {
forward = true
connection = false
pool = bigip_ltm_pool.trnz0.name
}
}
I get the following error:
╷
│ Error: HTTP 400 :: {"code":400,"message":"\"http-header\" may not be specified with \"forward\"","errorStack":[],"apiError":26214401}
│
│ with bigip_ltm_policy.trnz0-webapp,
│ on main.tf line 81, in resource "bigip_ltm_policy" "trnz0-webapp":
│ 81: resource "bigip_ltm_policy" "trnz0-webapp" {
│
╵
This happens because the provider is trying to change the first action, which is still inserting an HTTP Header, instead of removing it.
Separating the actions (and conditions!) in different objects could both help with policy reuse and keeping track of cases such as this where I'm not asking to modify a policy, but to delete one.
EDIT: looks like I can't even use a for cycle to dynamically create a list of rules! This needs to get more modular if we want to make it more usable
Hi @icovada,
Have you tried using AS3?
Hey... it works!
Not exactly what I was looking for but does the trick, thanks
EDIT: this is still not what I'm looking for, as I have to define a single AS3 declaration containing all objects inside a Tenant. If I define two declarations for the same Tenant with different content, it gets overwritten by whichever is pushed last