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

Provider produced inconsistent result after apply #412

Open
kdavis5 opened this issue Sep 27, 2023 · 4 comments
Open

Provider produced inconsistent result after apply #412

kdavis5 opened this issue Sep 27, 2023 · 4 comments
Labels

Comments

@kdavis5
Copy link

kdavis5 commented Sep 27, 2023

Describe the bug

When pushing or creating a new administrative tag using the resource panos_panorama_administrative_tag.application_tag I get the error "Provider produced inconsistent result after apply"

When applying changes to panos_panorama_administrative_tag.application_tag,
provider "provider["registry.terraform.io/paloaltonetworks/panos"]"
produced an unexpected new value: Root resource was present, but now
absent.

I get a warning but the tag does look like it installs in panorama. The firewall team commits later.
Next time I run the terraform file it looks like the tag never made it into the state file because TF wants to create the tag again. Same error results each time I run it without any changes.

Expected behavior

to get message that tag is created and a clean apply. No errors.
since I made no changes to the TF file, I would expect TF reads that state file and i get the message "No changes. Your infrastructure matches the configuration."

Current behavior

the error "Provider produced inconsistent result after apply"

When applying changes to panos_panorama_administrative_tag.application_tag,
provider "provider["registry.terraform.io/paloaltonetworks/panos"]"
produced an unexpected new value: Root resource was present, but now
absent.

each time I run the tf file it wants to build the tag again.

panos_panorama_administrative_tag.application_tag will be created

  • resource "panos_panorama_administrative_tag" "application_tag" {
    • comment = "built by terraform"
    • device_group = "shared"
    • id = (known after apply)
    • name = "hw_app:dept_fm_sedanshv"
      }

Here is the terraform resource block

create firewall application tag

resource "panos_panorama_administrative_tag" "application_tag" {
name = "hw_app:${local.aci_application_profile_name}"
comment = "built by terraform"
}

Possible solution

Not sure, error states: This is a bug in the provider, which should be reported in the provider's
own issue tracker.

Steps to reproduce

  1. happens every time I use the resource to add an administrative tag to panorama

Screenshots

Screen Shot 2023-09-27 at 12 01 08 PM

Context

I am using this resource to build out administrative tags to panorama so that they can be used as a tag to match components of an application and a predetermined security rule.

  • Version used: Terraform v1.3.7 and Panorama version 10.2.4-h2 and Provider version 1.11.1
@kdavis5 kdavis5 added the bug label Sep 27, 2023
@welcome-to-palo-alto-networks

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

@kdavis5
Copy link
Author

kdavis5 commented Sep 27, 2023

Upgraded to Terraform 1.5.7 with no difference to outcome.
After my initial run, I don't see the resource in my state file. That would explain why it wants to re-create the object on each run. Provider is not adding this to the state file. Also validated that Panorama is in fact installing the tag.

@chris3ware
Copy link

chris3ware commented Oct 19, 2023

I believe this is because of the colon in the tag name.

For example:

app:github produces the error described above even though the tag is added to panorama

but

app-github does not produce an error, the tag is added to panorama and the state file is updated.

@kdavis5
Copy link
Author

kdavis5 commented Oct 31, 2023

chris3ware, I tested that and you are correct. It does appear to be an issue with that colon. So I wonder if this is by design or still a bug. I would love to have that colon since it matches our current conventions.

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

No branches or pull requests

2 participants