VOTE: Aggregation of the current provider resources

[shinmog]

Short version: would you like fewer resources that better allow you to configure the entirety of something, or keep resources lean and super focused as things currently are?

Longer version: The current panos provider has over 150 resources and around 90 data sources but has only barely touched the surface of what configuring a PAN-OS in its entirety would need. As configurations get more complex and new resources get added to the provider, the current approach of keeping resources super narrowly focused puts more strain on everything:

• The computer executing Terraform, keenly felt by any user that has a plan that takes hours to compute, much less invoke any actual API call)
• Makes plan deployment when it finally begins take longer, since API calls are smaller
• Makes it harder as a user to tell if something is configured in it's entirety and would not lead to commit validation errors
• Harder on users just looking at a list of 100 resources to determine which are interconnected and which are standalone
• Harder on us as the provider's maintainers, in the form of file sprawl

As we are looking forward to the future of the panos provider, we are considering if users wouldn't be better served by aggregating resources together in places where it would make sense.

For example, if a user wanted to configure an ethernet interface, "ethernet1/2" with five ARP objects, this would require one panos_ethernet_interface block with five panos_arp blocks. These six resources would be tracked in state separately, and would result in 12 API calls during the creation process (read -> create for all six resources). This results in added pressure on the PC running terraform to generate the dependency graph, track it, and adhere to it.

Imagine instead a single resource that would take the ethernet interface config, as well as any statically defined ARP objects desired. A single resource that did both the interface config as well as the ARP objects would remove the need for panos_arp, which means less for users to keep track of. The CPU running Terraform has zero dependencies to deploy this, which speeds up plan execution time. The provider, containing all of this information, can then configure the interface and all five ARP objects in 2 API calls for create (read the whole thing -> create the whole thing). Fewer API calls directly translates into less time waiting for plan deployment to execute, and takes something that did required six Terraform threads to deploy to a single Terraform thread, freeing up those threads to deploy other config.

The farther from 6 resource blocks your specific Terraform plan is, the larger the realized performance gains would become.

Pros:

• Less resources / more impactful resources
• Confidence that if a resource deploys, that the configuration is actually valid
• Significant speedup in Terraform graph building time (terraform plan or the start of terraform apply when it refreshes state)
• Significant speedup in time spent waiting on API calls to execute, as each API invocation contains more information

Cons:

• Fewer resources means less granular control
• Fewer resources also means more complexity in the specs for resources that do exist