An efficient tool to execute configuration backups, network state snapshots, system readiness checks, and operating system upgrades of Palo Alto Networks firewalls and Panorama appliances.
[x] Ensure you are submitting your pull request to a branch dedicated to a specific topic/feature/bugfix. Avoid using the master branch for pull requests.
[x] Target your pull request to the main development branch in this repository.
[x] Ensure your commit messages follow the project's preferred format.
[x] Check that your code additions do not fail any linting checks or unit tests.
Pull Request Description
This pull request introduces a safeguard feature in the pan-os-upgrade tool to prevent compatibility issues when upgrading PAN-OS firewalls in an HA pair. The feature gracefully exits the upgrade process if the user selects an upgrade version that is two or more minor releases ahead of the current version and the firewalls are in an HA state.
What does this pull request accomplish?
Feature addition
Are there any breaking changes included?
[ ] Yes
[x] No
Changes made in this pull request
Added a new function check_ha_compatibility to assess the compatibility of the target PAN-OS version with the current version in an HA pair.
Updated the software_update_check function to call check_ha_compatibility when dealing with firewalls in an HA pair.
If the target version is incompatible, a warning message is logged, and the function returns False, preventing the upgrade from proceeding.
Updated docstrings for the check_ha_compatibility function to align with the project's documentation style.
Resolves issue
Resolves #109
Motivation behind this feature
When upgrading PAN-OS firewalls in an HA pair, selecting a version that is two or more minor releases ahead of the current version can lead to compatibility issues. If one firewall is upgraded to a version that is significantly ahead of its peer, it may not be able to rejoin the HA pair after the upgrade, putting itself in a suspended state. When the upgrade process begins on the other firewall, it issues an HA state switch over. If the peer is in a suspended state, neither firewall will be able to forward traffic, as they both operate in a suspended state.
This safeguard feature mitigates this issue by gracefully exiting the upgrade process when the specified conditions are met. It helps prevent users from accidentally causing HA pair incompatibility issues and ensures they are aware of the potential consequences before proceeding with the upgrade.
Is there anything the reviewers should know?
Please review the changes carefully, especially the logic in the check_ha_compatibility function, to ensure it accurately identifies potential compatibility issues based on the version numbers and HA state.
Here's a refined PR description based on the provided GitHub issue and changes:
Checklist for This Pull Request
🚨Please adhere to the guidelines for contributing to this repository.
Pull Request Description
This pull request introduces a safeguard feature in the pan-os-upgrade tool to prevent compatibility issues when upgrading PAN-OS firewalls in an HA pair. The feature gracefully exits the upgrade process if the user selects an upgrade version that is two or more minor releases ahead of the current version and the firewalls are in an HA state.
What does this pull request accomplish?
Are there any breaking changes included?
Changes made in this pull request
check_ha_compatibilityto assess the compatibility of the target PAN-OS version with the current version in an HA pair.software_update_checkfunction to callcheck_ha_compatibilitywhen dealing with firewalls in an HA pair.False, preventing the upgrade from proceeding.check_ha_compatibilityfunction to align with the project's documentation style.Resolves issue
Resolves #109
Motivation behind this feature
When upgrading PAN-OS firewalls in an HA pair, selecting a version that is two or more minor releases ahead of the current version can lead to compatibility issues. If one firewall is upgraded to a version that is significantly ahead of its peer, it may not be able to rejoin the HA pair after the upgrade, putting itself in a suspended state. When the upgrade process begins on the other firewall, it issues an HA state switch over. If the peer is in a suspended state, neither firewall will be able to forward traffic, as they both operate in a suspended state.
This safeguard feature mitigates this issue by gracefully exiting the upgrade process when the specified conditions are met. It helps prevent users from accidentally causing HA pair incompatibility issues and ensures they are aware of the potential consequences before proceeding with the upgrade.
Is there anything the reviewers should know?
Please review the changes carefully, especially the logic in the
check_ha_compatibilityfunction, to ensure it accurately identifies potential compatibility issues based on the version numbers and HA state.