Add NSX-T NAT rule support

[Didainius]

Implements NSX-T NAT rule support by adding NsxtNatRule and types.NsxtNatRule as well as methods edge.GetAllNsxtNatRules,edge.GetNsxtNatRuleByName, edge.GetNsxtNatRuleById, edge.CreateNatRule, nsxtNatRule.Update, nsxtNatRule.Delete, nsxtNatRule.IsEqualTo

A few caveats:

• API does not return ID of created object therefore it must be manually looked up by comparing as much fields as it is possible. To aid this nsxtNatRule.IsEqualTo is introduced to perform additional validations. edge.CreateNatRule also has non-standard task tracking and then uses nsxtNatRule.IsEqualTo internally to find ID of newly created rule.
• There are two new fields introduced in API V35.2+ (VCD 10.2.2+) - FirewalMatch and Priority. In order to support these fields all methods above will elevevate API version to exactly V35.2 (not higher) so that those fields can be used. There is a specific check Test_NsxtNatDnatFirewallMatchPriority to test exactly that
• New NAT rule type REFLEXIVE is supported in API V36.0. It also requires rule type to be specified in Type field instead of RuleType
• There is one field which was deprecated InternalPort and was changed to DnatExternalPort between existing versions. Because these functions automatically elevate API - one must know which field to use. Tests Test_NsxtNatDnatInternalPort and Test_NsxtNatDnatExternalPort test out this functionality.

Additionally:

• Functions queryOrgVdcByName, queryOrgVdcById, queryCatalogByName and queryCatalogById are improved to include orgName as filter (improves filtering accuracy in cases when org ID field is not accepted)

Note. Tests pass with nsxt tag on all NSX-T supported environments.

[dataclouder]

Some questions to answer

[dataclouder]

I understand that Type and RuleType may not both be there, but a comparison should be still viable. What am I missing?

Also, could you make a note on why these fields are not reliably comparable?

• InternalPort,
• FirewallMatch,
• Priority,
• Version,

[Didainius]

Also, could you make a note on why these fields are not reliably comparable?

Good question which led me to another round of thinking. I was carefully trying to match as many fields as possible (while still having comprehensible comparison code). Main problem for many fields is - behavior changes across API versions which can make this matching very messy - value comparisons differ based on version:

• Type and RuleType - the trick is - on API V36.0 one can set RuleType (deprecated) or Type field value (except the new REFLEXIVE which explicitly requires Type field). After READ it would return both RuleType and Type being set with the same value, unless it is REFLEXIVE(in that case it returns ruleType=null and type=REFLEXIVE)
• FirewallMatch - it exists only since API 35.2+ and has a default starting this version
• InternalPort - is deprecated since API V35.0+ and is replaced by DnatExternalPort
• Priority - is available only in API V35.2+
• Version - it is something that is automatically handled by API. When creating - you must specify none, but it sets version to 0. When updating one must specify the last version read, and again it will automatically increment this value after update. (probably it is meant to avoid concurrent updates)

We could probably even write smart rules for tested versions, but what I am more afraid of is that even using a known API version might break in future VCD versions as we already saw a few times before. I know that in future versions NAT should return ID after POST and that should not be required at all, but now we still have it.

For now I have put this comment as well into function docs.

Any other ideas? I will sleep on it to see if anything more pops up now as I refreshed this context.

[dataclouder]

This function assumes that apiVersion contains the valid version to be used when the client version is < 35.2.
But if apiVersion is empty or invalid, we will have an unrecoverable error.
Possibly we should retrieve apiVersion within elevateNsxtNatRuleApiVersion and return (string error).
Or you may have a better idea.

[Didainius]

The point with this function was that I would always feed it with output of

endpoint := types.OpenApiPathVersion1_0_0 + types.OpenApiEndpointNsxtNatRules
apiVersion, err := client.checkOpenApiEndpointCompatibility(endpoint)

However. I had in mind that one day - if such approach of "stepped" elevation (elevation to known verified API versions when possible) could be more generic for those resources that need it.

I have made a second attempt and introduced a function client.getOpenApiHighestElevatedVersion for internal use which is similar to checkOpenApiEndpointCompatibility, but is capable of picking highest possible version from a predefined list endpointElevatedApiVersions.

We could just use "highest" version supported by VCD API, but that is risky as pointing it to future VCD version might just break it (if some field is removed in future API version).

Have a look and share if it looks better. This is yet hard to comprehend if it is a silver bullet as there is just one use case, but this was my early vision of how it could look in a more generic fashion.