Upgrade failure during the migrate config task in VMware AVI load balancer GSLB setup.

Products

• VMware Avi Load Balancer

Issue/Introduction

• The upgrade from version 31.2.1 to 31.2.2 fails during the upgrade of the follower site in a GSLB setup.
• The following error occurs during the migrate config task:
• Under the /var/log/upstart/upgrade-coordinator.log: on the controller leader node.
  • "/opt/avi/python/bin/portal/nonportal/management/commands/import_configuration.py", line 125, in handle     importer.configuration_import(configuration)   File "/opt/avi/python/lib/avi/config_migration/export_import.py", line 2483, in configuration_import     raise Exception(self.upgrade_task_journal.display_error) Exception: Errors countered for ['Gslb']. Field 'replication_policy' was deprecated in 31.2.1 and is no longer supported For further details please refer to the journals. /opt/avi/log/task_journal/upgrade_import_config.json

Environment

VMware AVI Load Balancer Version: 31.2.1

Cause

The failure is triggered when a GSLB follower site undergoes a sequential upgrade (two or more version jumps) while the GSLB leader site is still running an older major version.

• Example Scenario:
  • Initial State: Leader and Follower are both on version 22.1.7.
  • First Jump: Follower is upgraded from 22.1.7 to 31.2.1 (Leader remains on 22.1.7).
  • Second Jump: Follower is upgraded from 31.2.1 to 31.2.2. (Leader still remains on 22.1.7).
    
    
• The failure is caused by a Protobuf schema mismatch between the GSLB leader and follower during a version-mismatched state.
• In the 31.2.1 release, the replication_policy field was deprecated and moved from the GSLB level to the site level.
• While the API server on the 31.2.1 Follower site correctly removes this deprecated field during standard API migrations, the field can be re-introduced via internal streaming.
• The gslb_remote_worker on the Leader (running 22.1.7) continues to stream GSLB updates that include the legacy replication_policy field:

  • replication_policy: <replication_mode: REPLICATION_MODE_CONTINUOUS>

• The follower gslbportal receives this update and saves the deprecated field back into its database. When the follower is then being upgraded to 31.2.2, the configuration migration utility encounters this unexpected field, causing the task to fail.

Resolution

Workaround:

• To resolve this issue and ensure a successful upgrade path, follow the "interleaved" upgrade methodology to maintain version parity across the GSLB.
• Once a follower site is upgraded, immediately upgrade the GSLB leader site to the same version before performing any subsequent upgrades or configuration changes on the follower.
  • Correct Sequence: Upgrade GSLB Follower (22.1.7 --> 31.2.1) -->Upgrade GSLB Leader (22.1.7 --> 31.2.1) --> Upgrade GSLB Follower (31.2.1 --> 31.2.2).

Permanent fix:

• This logic conflict in how the gslb_remote_worker handles deprecated Protobuf fields has been addressed in version 32.1.1 and later.