Since will be fixed separately, moving this task to Ready for merge status.

New FB:

Test 1:
Install using helm/cli in default everest namespace with all operators.
Create an unsharded db of 3 nodes for 7.0.15-9. Enable scheduled backups and PITR.
Create a sharded db of 2 shards, 3 nodes (default config) for 7.0.15-9. Enable scheduled backups and PITR.
After a scheduled backup, upgrade both db to 8.0.4-1.

Result: Both db restart and come up. The version is changed to 8.0.4-1. The upgrade is successful.

Test 2:
Install using helm in a1 namespace with only mongodb operator.

Create an unsharded db of 1 node for 6.0.9-7.
Create a sharded db of 1 shard, 1 node, 1 config, 1 router for 6.0.9-7.

Add data in both db. Shard the data for sharded db. Take scheduled backup of both db.

Upgrade sharded db to 7.0.15-9.
Result: Upgrade is successful.

Upgrade unsharded db to 7.0.8-5.
Result: Upgrade is successful.

Edit the unsharded db and increase the nodes to 3.
Upgrade unsharded db to 8.0.4-1.
Result: Upgrade is successful.

Edit the sharded db and increase the shards to 4, nodes to 3, config to 3, routers to 3.
Upgrade sharded db to 8.0.4-1.
Result: Upgrade is successful.

Note: Db nodes, routers, cfg restart during the upgrade.

Test 3:
Retest scenario after the upgrade fix - added upgrading status in
Tested with FB:

Install 1.5.0 using cli, a1 namespace has mongodb only.

Create two unsharded db of 3 nodes for 6.0.15-12.
Create a sharded db of 3 shards, 3 nodes, 3 config, 3 routers for 6.0.15-12.
Add data in all db. Shard the data for sharded db. Take scheduled backup of all db. Enable PITR. Enable monitoring.

Upgrade to FB

Result: Upgrade to FB is successful

Upgrade to minor version
Upgrade unsharded1 db from 6.0.15-12 to 6.0.19-16.
Upgrade sharded db from 6.0.15-12 to 6.0.16-13.
Upgrade unsharded2 db from 6.0.15-12 to 6.0.19-16.
Result: Upgrade is successful for all db.

Upgrade to major version
Upgrade unsharded1 db from 6.0.19-16 to 7.0.14-8.
Upgrade sharded db from 6.0.16-13 to 7.0.12-7.
Result: Upgrade is successful for both db.

Take scheduled backup of both db.

Upgrade to major version again
Upgrade unsharded db from 7.0.14-8 to 8.0.4-1.
Upgrade sharded db from 7.0.12-7 to 8.0.4-1.
Result: Upgrade is successful for both db.

Take scheduled backup of both db.
Restore sharded and unsharded db using latest PITR.
Result: Restore is successful.

Note: After upgrading, downgrading of version is not allowed. The previous versions are not displayed in the Upgrade page, only new versions are displayed for upgrading further.

Issues pending for fix which may be dependent on operator changes

2. - This is in progress.

4. Upgrades are not deterministic, it is difficult to know how much time an upgrade will take.

If databases are upgraded successively, then all of them remain in the Upgrading state till the upgrades are completed. This is due to . The upgrade time is not deterministic, hence it is difficult to know how much time the upgrade will take to complete and the database will stay in Upgrading state till that time.

In latest FB, the current version is not displayed for selection. Also, the next major version 7.0 is displayed, 8.0 is not displayed so that version 7.0 can’t be skipped

Thanks , that’s correct, 1 and 3 were the only issues that were introduced in this ticket. Where as 2, 4 and 5 already existed for the minor version upgrades.