provider/consul: consul_key_prefix resource

[apparentlymart]

This new resource is an alternative to consul_keys that manages all keys under a given prefix, rather than arbitrary single keys across the entire store. This is based on my proposal in #5211, but differs from that earlier proposal due to some further design iteration.

• Implementation
• Tests
• Documentation

The primary change to the design is to refer to the idea of a "prefix" rather than a "subtree", since that is more consistent with Consul's data model and terminology used within its API.

Here is an example of how it might be used:

resource "consul_key_prefix" "baz" {
    path_prefix = "test/sandwich/"

    subkeys = {
        // Individual sub-keys
        "cheese_type" = "chevre"
        "meat_type" = "ham"
        "bread_type" = "baguette"

        // Consul has a convention where sets can be managed as a "folder" of values.
        // We can create such a set, and this resource will automatically add/remove members
        // as required.
        "veggies/tomato" = "tomato"
        "veggies/lettuce" = "lettuce"
    }
}

This will create the following full keys in Consul:

• test/sandwich/cheese_type
• test/sandwich/meat_type
• test/sandwich/bread_type
• test/sandwich/veggies/tomato
• test/sandwich/veggies/lettuce

Here's an example of a diff created when changing to a different kind of cheese, leaving everything else unchanged:

~ consul_key_prefix.baz
    subkeys.cheese_type: "chevre" => "brie"

The key advantage of this resource over consul_keys is that it is able to detect and delete keys that are added outside of Terraform, whereas consul_keys is only able to detect changes to keys it is explicitly managing. It will also delete the entire subtree under the given prefix when the resource is deleted, since in this case Terraform is considered to be exclusively managing that entire keyspace.

Along with that initial motivation, this resource also serves to serve the need that motivated my earlier proposal #3164: rather than using Terraform's remote state mechanism as a means to pass around bundles of key/value pairs, this resource provides a robust means to manage such bundles directly within Consul, at least so long as Consul was the backend being used with terraform_synthetic_state (which it is in my case). One could imagine a similar resource aws_s3_bucket_object_prefix that manages a collection of related S3 bucket objects in the same way, since S3's data model is similar to Consul's.

[jen20]

This LGTM! Thanks @apparentlymart!

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.