You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We encountered a bug where the panos_custom_url_category resource could create multiple objects pointing to a single URL category in Panorama, which caused issues during subsequent changes.
Expected behavior
panos_custom_url_category resource should not be able to create new objects that points to an existing URL category in Panorama
Current behavior
Currently panos_custom_url_category resource could create multiple objects pointing to a single URL category in Panorama.
eg. following code is accepted and it's able to apply:
After this code is applied, both resource panos_custom_url_category.prelude and panos_custom_url_category.qualtrics are pointing to Panorama URL category object "prelude", and this apply would update Panorama URL category "prelude" to use sites ".qualtrics.com"; The next plan and apply would update Panorama URL category "prelude" to use sites "*.prelude.com", etc. This would be a loop.
And it's difficult to fix the issue, we tried:
remove new resource panos_custom_url_category.qualtrics - it's not able to apply because in the plan it's trying to remove the existing URL category "prelude"
manually add URL category "qualtrics" in panorama, and correct the code as following
delete both qualtrics & prelude in TF code and apply - TF apply would try to delete both resource panos_custom_url_category.prelude and panos_custom_url_category.qualtrics, one of them would be deleted successfully, the other one would have error 'object not found'
Possible solution
To prevent this issue, panos_custom_url_category resource should not be able to create new objects that points to an existing URL category in Panorama
It would be better to have some way to check and block this kind of change.
# new code #
resource "panos_custom_url_category" "qualtrics" {
name = "prelude"
device_group = local.device_groups.jetstream
sites = ["*.qualtrics.com"]
type = "URL List"
lifecycle { create_before_destroy = true }
}
Screenshots
please see above screenshots
Context
This bug can be triggered easily with a typo. The only that we can fix it is to roll back the terraform state back to the time that the 2nd object was not created.
Your Environment
Version used: panos version 1.11.0; terraform version 1.0.11
Palo Alto Networks Panorama 10.2.7-h3
Operating System and version (desktop or mobile): desktop
Link to your project:
The text was updated successfully, but these errors were encountered:
Describe the bug
We encountered a bug where the panos_custom_url_category resource could create multiple objects pointing to a single URL category in Panorama, which caused issues during subsequent changes.
Expected behavior
panos_custom_url_category resource should not be able to create new objects that points to an existing URL category in Panorama
Current behavior
Currently panos_custom_url_category resource could create multiple objects pointing to a single URL category in Panorama.
eg. following code is accepted and it's able to apply:
After this code is applied, both resource panos_custom_url_category.prelude and panos_custom_url_category.qualtrics are pointing to Panorama URL category object "prelude", and this apply would update Panorama URL category "prelude" to use sites ".qualtrics.com"; The next plan and apply would update Panorama URL category "prelude" to use sites "*.prelude.com", etc. This would be a loop.
And it's difficult to fix the issue, we tried:
TF plan shows:
TF apply shows error "Object not found"
Possible solution
To prevent this issue, panos_custom_url_category resource should not be able to create new objects that points to an existing URL category in Panorama
It would be better to have some way to check and block this kind of change.
Steps to reproduce
Screenshots
please see above screenshots
Context
This bug can be triggered easily with a typo. The only that we can fix it is to roll back the terraform state back to the time that the 2nd object was not created.
Your Environment
The text was updated successfully, but these errors were encountered: