Bug: Version 2.0.0 Long Plan Times

[flemingdp]

Terraform and Provider Versions

terraform version
Terraform v1.4.6
on linux_amd64
+ provider registry.terraform.io/jeremmfr/junos v2.0.0

Terraform Configuration Files

This is a simplified version of our Terraform HCL with some pieces that seem relevant.

terraform {
  required_providers {
    junos = {
      source  = "jeremmfr/junos"
      version = "2.0.0"
    }
  }
}

# Configure the Junos Provider
provider "junos" {
  ip   = "100.100.100.100"
  port = 830
}


locals {
  address_sets = flatten(
    [
      {
        name        = "test"
        address     = ["1.1.1.1/32"]
        address_set = null
        description = null
      }
    ]
  )
}

variable "fake_create_with_setfile_enabled" { default = "FALSE" }
variable "fake_create_with_setfile_path" { default = "" }

resource "junos_null_commit_file" "initial-commit" {
  count    = var.fake_create_with_setfile_enabled == "TRUE" ? 1 : 0
  filename = var.fake_create_with_setfile_path
}


resource "junos_security_address_book" "global" {
  name = "global"
  dynamic "address_set" {
    for_each = local.address_sets
    content {
      name        = address_set.value.name
      address     = address_set.value.address
      address_set = length(address_set.value.address_set) > 0 ? address_set.value.address_set : null
      description = address_set.value.description
    }
  }
}

Expected Behavior

With version 1.33.0 we could run a plan on an empty state and it would take 39 seconds.

Actual Behavior

Now we are finding that a plan will take 19 minutes and 52 seconds with the 2.0.0 version of the provider.

Steps to Reproduce

1. terraform plan

Additional Context

We have been successfully running this provider for a while now, and are working to make our HCL compatible with the new 2.0.0. We have addressed the errors around setting fields to null rather than false and empty arrays to null where needed as well. We can now successfully perform a plan, but are seeing the long run times.

Also I wanted to note the use of the junos_null_commit_file.
When we detect there is no statefile we will set fake_create_with_setfile_enabled to true.
This seemed to speed things up on initial plan/deploy in the past.

[jeremmfr]

Hi 👋

As I said in the previous issue, the source of then problem seems to come from the terraform-plugin-framework and with a lot of Block Sets.
I tested and I have a plan in 20 seconds with 500 block items (instead of ~ 1 second with SDK plugin or in List mode).

@computeracer Approximately how many blocks do you have when the plan take 19 minutes ?

[flemingdp]

Thank you for the reply @jeremmfr. I will need to look deeper. Can you explain what a block set is to make sure I count the right things? The plan is about 650 resources, with an estimated 3100 total of what I think are blocks within these 650 resources (address_sets, network_addresses, dns_names, and policies). My next step I think is to start splitting the config to see where the parts that take the longest are. Might help narrow it down.

[jeremmfr]

Thanks for the reply, it's right those blocks and that's what I was looking for.
I'm going to open a bug issue on the Hashicorp terraform-plugin-framework repository.

[jeremmfr]

First improvement in Terraform plan time with #507

[jeremmfr]

Hi @computeracer 👋 ,
I released a new version v2.1.0 which contains the first improvement on plan time with block sets.
Could you tell me what level of benefit you have with this new version for your configuration?

[flemingdp]

Hi @jeremmfr,
I apologize for the delay. We got to retest some of our work with the new version. The plan times have shrunk a little bit and are now about 16.5 minutes.

[jeremmfr]

I'm a little surprised by this result. A gain of half the time was expected.
@computeracer Would it be possible to send me an example of your Terraform configuration that generates this Plan time so that I can test it further?

[flemingdp]

@jeremmfr thank you for reaching out again on this. With the comments in the related issue, I thought there would not be much of a change in run time. I took the original time from our pipeline which I forgot does a few other things that bumped it up to the 16.5 minutes. I ran the changes locally with our config and version 2.1.0 and it takes 4.5 minutes. This is still up from the 24 seconds plan time with version 1.33, but quite an improvement. Thank you!