VOTE: Community preference for specifying the location / XPATH

[shinmog]

Short version: Vote on how you'd like to see XPATH represented in v2 of the panos Terraform provider.

Longer version: Currently, params that are used to create the XPATH of an object are mixed in with the spec of
the object stored at that XPATH. We are considering changing this, but would like some feedback from the community
on what they prefer. Please note that even if a particular choice is the most popular, we may choose to go with a less popular choice. This poll is just to get an idea what users would like to see.

The goal of changing how location is specified is to better bring attention to which params are used for the location of the config.

Pros:

• Ideally would make it very clear to users how to choose the eventual location of a config, and what is required from them to place the configuration there
• Would allow Terraform itself to validate location / XPATH params using validators (this would surface errors in the location much faster)
• Would make the location of a particular config more obvious when eyeballing the HCL as well as reading documentation for data sources and resources
• Would potentially allow for different location options for existing resources without requiring an ID change or a schema migration (this more affects us as provider maintainers than users)

Cons:

• Could end up looking more complicated to users, since it would be a nested structure
• Would introduce way more curley braces to resources across the board for the panos provider
• Along those lines, would guarantee that no panos v1 spec works with panos v2, since the location is specified differently

IMPORTANT NOTE: since this will be a v2, voting for keeping things the way they are now does not mean that your favorite resource that you have thousands of will remain untouched and you won't have change your HCL at all. There is no guarantee that any spec will stay the same in v2. This is really just a vote for what you would prefer going forward.

Here's an example of how such a change could affect the HCL to specify an address object, for example (note that the name location or anything else beneath it is not finalized, so don't focus on the name, just the syntax and grouping):

resource "panos_address_object" "example" {
    # In shared
    location = {
        shared = true
    }

    # In vsys1
    location = {
        vsys = {}
    }

    # In vsys2
    location = {
        vsys = {
            name = "vsys2"
        }
    }

    # In a device group
    location = {
        device_group = {
            name = "myDeviceGroup"
        }
    }

    # Rest of the config goes here
    .....
}

For more spread out objects, such as TACACS+ server profiles, between both NGFW and Panorama, these can exist within PAN-OS in numerous places:

• (Panorama) On Panorama for Panorama use only (today: leave all of template / template_stack / vsys empty)
• (Panorama) In shared within a template (today: specify template and vsys="shared")
• (Panorama) In a vsys within a template (today: specify template and vsys="vsys1")
• (Panorama) In shared within a template stack (today: specify template_stack and vsys="shared")
• (Panorama) In a vsys within a template stack (today: specify template_stack and vsys="vsys1")
• (NGFW) In shared (today: vsys="shared")
• (NGFW) In a vsys (today: vsys="vsys1")

Changing the above resource to this new nested approach would help clarify the intended location of the config (again, neither location nor any of the names underneath are finalized, just focus on the syntax):

resource "panos_tacacs_plus_profile" "example" {
    # On panorama itself
    location = {
        panorama_itself = true
    }

    # In shared within a template
    location = {
        shared_within_a_template = {
            template = "myTemplate"
        }
    }

    # In vsys1 within a template
    location = {
        vsys_within_a_template = {
            template = "myTemplate"
            # Within this context, vsys can default to "vsys1" so it could be unspecified
            # vsys = "vsys1"
        }
    }

    # In shared within a template stack
    location = {
        shared_within_a_template_stack = {
            template_stack = "myTemplateStack"
        }
    }

    # In vsys2 within a template stack
    location = {
        vsys_within_a_template_stack = {
            template_stack = "myTemplateStack"
            vsys = "vsys2"
        }
    }

    # In shared on NGFW
    location = {
        ngfw_shared = true
    }

    # In vsys1 on NGFW
    location = {
        vsys = {}
    }

    # In vsys2 on NGFW
    location = {
        vsys = {
            vsys = "vsys2"
        }
    }

    # Rest of the config here
    .....
}

Thanks in advance!

[mvangoor]

@shinmog I have been looking at the rc1 of the new terraform provider and stumbled upon this location required on every resource.

This made me wonder why you would not do this at provider level and initialize multiple providers if and when necessary?
Examples are AWS with multiple regions (requires 1 provider per region), Azure with more than 1 subscription (requires 1 provider per subscription), etc.
Example: https://discuss.hashicorp.com/t/creating-aws-resources-with-terraform-across-multiple-regions/25010

Very curious to hear more on this.