Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Template / template_stack conflict yet are enforced #294

Open
cyphermox opened this issue Jul 16, 2021 · 3 comments · May be fixed by #295
Open

Template / template_stack conflict yet are enforced #294

cyphermox opened this issue Jul 16, 2021 · 3 comments · May be fixed by #295
Labels

Comments

@cyphermox
Copy link

Describe the bug

I imported my existing panorama config for zones; those include both a template and template_stack values set. Defining the zones in terraform code to have a snapshot of the existing config (basically, importing, then adjusting terraform code until terraform plan shows no changes to be applied), leads to constraints impossible to satisfy:

Error: "template_stack": conflicts with template

  on zones.tf line 1, in resource "panos_panorama_zone" "Dev":
   1: resource "panos_panorama_zone" "Dev" {

Error: "template": conflicts with template_stack

  on zones.tf line 1, in resource "panos_panorama_zone" "Dev":
   1: resource "panos_panorama_zone" "Dev" {

Yet:

  # panos_panorama_zone.Dev must be replaced
-/+ resource "panos_panorama_zone" "Dev" {
      ~ id             = "mytmpl:mytmpl_stack:vsys1:Dev" -> (known after apply)
      ~ interfaces     = [] -> (known after apply)
        name           = "Dev"
      - template       = "Stack8-Edge" -> null # forces replacement
        # (6 unchanged attributes hidden)
    }

Expected behavior

It should be possible to define a zone based on its existing imported properties, such that 'terraform plan' is a no-op (as a basis for adding new panorama/panos config).

resource "panos_panorama_zone" "Dev" {
  name = "Dev"
  mode = "layer3"

  template = panos_panorama_template.mytmpl.name
  template_stack = panos_panorama_template_stack.mytmpl_stack.name

  include_acls   = []
  exclude_acls   = []
  enable_user_id = false
}

Current behavior

Terraform plan errors with a schema conflict, or produces a plan which involves potentially destructive changes.

Possible solution

Not making template and template_stack conflict.

Steps to reproduce

See above.

Screenshots

Screenshot from 2021-07-15 20-20-14

Screenshot from 2021-07-15 20-20-43

Context

See above

Your Environment

Ubuntu 20.10 / python 3.8.10
Terraform panos provider: 1.8.3
Panorama 9.1

@cyphermox cyphermox added the bug label Jul 16, 2021
@welcome-to-palo-alto-networks

🎉 Thanks for opening your first issue here! Welcome to the community!

cyphermox added a commit to cyphermox/terraform-provider-panos that referenced this issue Jul 16, 2021
PaloAltoNetworks#294)

The template and template_stack objects are enforced when running
plan/apply against imported objects; otherwise the engine would
want to completely replace the objects, which would likely cause
consistency issues with the rest of the configuration.

Since they are both enforced; they can't also be conflicting; that
leads to an impossible scenario where you must but can't define
both a template and template_stack.

Signed-off-by: Mathieu Trudel-Lapierre <mtrudel@stack8.com>
@cyphermox cyphermox linked a pull request Jul 16, 2021 that will close this issue
4 tasks
@shinmog
Copy link
Collaborator

shinmog commented Dec 8, 2021

Sorry for the delay in looking at this.

So looking at your config, your terraform plan file is incorrect, so I believe the provider to be doing the correct thing here. A Panorama Zone will set either in a template or a template stack from an PAN-OS XPATH perspective. If I create a template, tem1 and then create a L3 ethernet interface ethernet1/2, then create a zone named foobar in vsys1, I am able to import this into Terraform.

Here's my plan file for the import:

resource "panos_panorama_zone" "x" {}

Here's me trying to import this resource into Terraform:

shell$ terraform import panos_panorama_zone.x 'tem1::vsys1:foobar'
panos_panorama_zone.x: Importing from ID "tem1::vsys1:foobar"...
panos_panorama_zone.x: Import prepared!
  Prepared panos_panorama_zone for import
panos_panorama_zone.x: Refreshing state... [id=tem1::vsys1:foobar]

Import successful!

The resources that were imported are shown above. These resources are now in
your Terraform state and will henceforth be managed by Terraform.

shell$ terraform show
# panos_panorama_zone.x:
resource "panos_panorama_zone" "x" {
    enable_user_id = false
    exclude_acls   = []
    id             = "tem1::vsys1:foobar"
    include_acls   = []
    interfaces     = [
        "ethernet1/2",
    ]
    mode           = "layer3"
    name           = "foobar"
    template       = "tem1"
    vsys           = "vsys1"
}
shell$ 

Just copy / pasting that into my plan file (and removing the id param, then terraform show shows a noop:

shell$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

panos_panorama_zone.x: Refreshing state... [id=tem1::vsys1:foobar]

------------------------------------------------------------------------

No changes. Infrastructure is up-to-date.

This means that Terraform did not detect any differences between your
configuration and real physical resources that exist. As a result, no
actions need to be performed.
shell$ 

Based on what I see in your config, the correct config for you is possibly template=Stack8-Edge (panos_panorama_template.mytmpl.name) with an empty template stack.

The fact that the template Stack8-Edge is in the template stack Stack8-Edge_mig is irrelevant here. The GUI shows comprehensive config, which obscures where things are actually located, so your params need to reflect where the object is actually configured at.

@kbcz1989
Copy link

Any chance to get some movement here @PaloAlto?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants