Add support for absolute rule positions

[harhan]

The API supports using absolute rule positions, while the provider does not. When using loops to generate rules, for instance from a json/tfvars set, it is not possible to reference previous rules due to circular references.

Please add support for integer input of absolute rule numbers in the position field.

PS! This change also has to support changing rule ordering, that is moving/inserting rules.

[deutmeyerbrianpfg]

Another option is to create a section title at the bottom and then make every access rule position to be above said section title. We found that even before using using terraform that specifying a position number was unreliable, given how the rule base was changing.

In the end, we have layers for the different "zones" or traffic "directionality" with a cleanup rule at the bottom, a title section header above that and every rule created gets created above that section title header. This way there isn't any confusion in Terraform.

[harhan]

Thank you; using inline layers and zones is my intention as well. Though customer requirements are not compatible with this approach at the moment. I've made some logic in a preparatory script creating tfvars in json format and calculating which rule belongs after the next. It would of course be a lot easier if one didn't have to use non terraform measures.

[deutmeyerbrianpfg]

You don't have to use zones/inline layers... you just need a section title or rule (like cleanup) where you can make sure all the new rules get built above.

[chkp-alonshev]

Hi @harhan , this feature was already asked in #58 As mentioned there: "Because of idempotent reasons and the fact that terraform runs on parallel it's tricky to support position by rule number. It's actually relevant only when modify single rule each time but when modify more than one rule, order of executions isn't known for us so the rule position can be change or not to be like the user meant. This is why we support only relative to ensure positioning is correct anytime."

Thank you, Alon

[harhan]

Could you support using a custom field as the anchor in stead of name or ID? In lieu of features that are more automation compatible, this would be a more robust.

[chkp-alonshev]

This feature is not supported in the API (the add command does not require name, but the set command requires name or uid, and therefore we need to mention a name or a uid) so we will be able to support it only if the API will.

[harhan]

Why is it that you cannot have some logic in the provider, is it some terraform limitation that stops you from putting more features? If you create a rule with the API, name is not required. The only fields that are is layer and position, which should be enough if the uid is used as key in the state. It is in fact a bit weird that we have to rely on something that is changeable by other users, like name, to uniquely identify a rule. Since it is impossible to know the UID before the rule is created, this logic should be part of the provider/state. Is this impossible?