Summary:
Controller managed gateway software upgrade is ‘all’ or ‘nothing’; works upgrading up to 7.1.x Gateway managed software upgrade allows granular selection; Jira open as upgrade to 7.1.x an issue, image upgrade is also available. The current ‘mc-transit/mc-spoke’ modules do not have the software/image upgrade parameters exposed, however, it’s easy enough to update the underlying resources and then locally source as custom modules. REF: Upgrading Aviatrix -
WHY
Customer’s looking to have option to maintain Aviatrix controller and gateway software upgrades via Terraform rather than controller GUI.
(Also image upgrades for gateways done at the respective module level)
EXAMPLE
Basic layout for testing, there are two methods:
Opt1. Let controller manage gateway software upgrades (image upgrade not possible) Note/.
The controller manages the gateway software upgrades, but cannot manage image upgrades, this can be done at the gateway module level (assuming the customized module is used as in Opt2)
BEWARE - Setting ‘manage_gateway_upgrades = false’ and setting ‘target_version = 7.0’ will attempt to update the controller to that version (if not already set to this version), not ideal if it wasn’t planned and potentially could result in gateways being N-2 versions behind.
For Opt1 testing, since the controller manages the upgrades, the normal mc-transit and mc-spoke modules can be used and sourced from Terraform registry
Pro: Controller manages the gateway upgrades as soon as controller is upgrade
Con: All or nothing, cannot select gateways; no image upgrade facility
Opt2. Let the gateways manage software (and image upgrades)
Note/.
The mc-transit and mc-spoke modules currently do not have the ‘software_version’ and ‘image_version’ parameters built-in, however, under the hood it leverages resource ‘aviatrix_transit_gateway’.
For Opt2 testing here, the module was customized to add the software and image parameters support by using a locally sourced module (more details see below)
Pro: Selective gateway software upgrade; image upgrade available
Con: Higher admin overhead to ensure gateway software upgrade keeps up with controller sofware upgrades; currently unable to upgrade to 7.1.x
Pre-requisite
Deploy controller running software version 6.9 (allows testing of multiple hops .. 7.0 , 7.1)
Opt1 - Controller managed software update
Deploy transit (and spoke) using normal mc-modules; status as below (6.9.733)
2. Set target_version and ‘manage_gateway_upgrade =true’ on this Terraform code; run Terraform Plan
3.The PLAN → APPLY
Gateway managed software and image upgrade
1. Comment out ‘target_version# and set ‘manage_gateway_upgrade = false’ on this Terraform code;
set target when looking to update the controller
(ensures that the controller doesn’t inadvertently get upgraded and also the gateways are not managed by the controller).
2.Deploy transit gateway using custom mc-module
3. Update the controller software first, uncomment the ‘target_version’ > Terraform PLAN > APPLY
3.1 Controller software upgrade plan
4. Update the transit gateway Terraform configuration; run Terraform PLAN > APPLY
In this example, note the software version is stated with ‘patch version’ this allows Terraform state to be complete, the software upgrade will still work with 7.0.
Also, specifying the image upgrade at same time if appropriate will get this done.
With terraform be precise with the software version, that is specify the patch version, e.g. 6.9.733, if the patch version is not specified and instead 6.9, though the gateway will be brought up to the 6.9.latest version correctly (in this case 6.9.733), running a terraform plan will see a discrepancy e.g. Plan will throw up 6.9 → 6.9.733
4.1 Gateway software upgrade plan
Other
A. Example of GW managed image upgrade + software upgrade (note controller already upgraded to 7.0)
Result:
B. Controller Managed Gateway upgrade to 7.1.x works, BUT gateway managed upgrade fails.
With controller managed, upgrading the gateways to 7.1 works, however, using gateway managed to bring the gateways up to 7.1 there is currently an issue -
Gateway led software upgrade to 7.1 - error seen:
C. PostMan API calls to upgrade gateway software to 7.1.x is successful
Postman API call gateway upgrade works.
Note/. There is a safeguard below for image upgrade, ensures HA pair are not upgraded at same time
e.g.
Example of successful API call
Result :
REPO: used with this testing
GitHub repoYou don't have permissions to view this data in GitHub
JIRA: