RDE (Runtime Defined Entities) framework support with RDE resource and data source (3/3)

[adambarreiro]

Design details

computed_entity vs input_entity/input_entity_url

There is a common use case for RDEs where they are used by 3rd party components that perform continuous updates on them, which are expected and desired. This conflicts with Terraform way of working, as doing a terraform plan would reveal the required actions to remove every single change done by those 3rd party tools, which we don't want in this case.

To add compatibility with this scenario, there are two important arguments, input_entity and input_entity_url,
and one important computed attribute, computed_entity.

If the RDE is intended to be managed only and exclusively by Terraform, the contents of the input JSON should always match with those retrieved into computed_entity. Otherwise, only computed_entity will reflect the current state of the RDE in VCD, whereas input_entity and input_entity_url will only specify the RDE contents that are needed either on creation or in a deliberate update that will cause the RDE contents to be completely overridden.

As per this last point, one needs to be careful when updating input_entity or input_entity_url, as Terraform will apply
whatever changes were done, ignoring the real state from computed_entity. To perform a real update, one
needs to check the contents of the computed_entity and do some diff with the original input.

resolve and resolve_on_destroy

RDEs must be resolved to be used or deleted, and this operation can be done either by Terraform with resolve=true, or by a 3rd party actor that will do it behind the scenes (resolve=false). To cover this last scenario, the RDE resource also has an argument resolve_on_destroy so Terraform can destroy the RDE if it was not resolved by anyone.

Non-unique imports

RDEs uniqueness is only granted by their ID. This means that the combination of vendor, nss, version and name does not guarantee its uniqueness. One can have multiple RDEs with the same values of vendor, nss, version and name.

In order to have a decent implementation of the terraform import operation, this PR implements three ways of importing:

• list@vendor.nss.version.name: This is the way to list all available RDE identifiers of the given type and name. Import will exit without performing any other operation. This way the users can somehow decide which RDE they want to import (if the ID gives some information to them, that is)
• rde-id: Import by RDE ID, which is unique.
• vendor.nss.version.name.position import by type, name and position. Position is a natural number that starts from 1.

RDE saga:

• Defined Interfaces PR: RDE (Runtime Defined Entities) framework support with Runtime Defined Entity Interfaces resource and data source (1/3) #965
• RDE types PR: RDE (Runtime Defined Entities) framework support with RDE Type resource and data source (2/3) #973

[dataclouder]

First pass

[Didainius]

I have tried it and approving, but have a look at binary tests as they need some skip directives - for example vcd.TestAccVcdRde-Resolve.tf binary test will not be skipped, but it will fail