Automate Major Upgrade Free Space Estimation Updates

[sean-horn]

User Story

As an Automate User, I need to have accurate free space estimation for major upgrade migrations. Otherwise, after the migration is done, I may find that I have 0% remaining in /hab, or a few megabytes at best. This creates an emergency situation immediately after the major upgrade.

In particular, for the migration from Elasticsearch to Opensearch in the upgrade to Automate 4.x, the system needs to make sure adequate free space will be available before the upgrade proceeds.

Acceptance Criteria

• If I start with 10GB free space in /hab and am currently using 50GB for Elasticsearch, I should be informed that I need to add at least 140GB so that migration of the search index to OpenSearch completes and the rest of the upgrade has enough space to finish
• If I start with 150GB free and am using 100GB for Elasticsearch, I should be told to add 50GB more space before proceeding with the upgrade
• In general, having 50% free space available + space for 2 copies of the search index data during a major upgrade is the safe zone, looking at the above examples. So, double the current used search index space, then maintain 50% free space in the /hab area
• After the upgrade, the extra space can be removed, after the old search index data copy has been removed
• The Warning box "Your drive should have a minimum of sixty percent of free space to start the major version upgrade." at Major Upgrade should be removed. The upgrade checker should calculate the proper amount of space required to do the major upgrade, and warn the user otherwise, as in the examples above

Definition of Done

• All things specified in User Story Acceptance Criteria should be fulfilled
• Smoke Test done
• Ensure Build and Integration Pipelines are Green

[Stromweld]

After the upgrade, the extra space can be removed, after the old search index data copy has been removed

I'd be careful of this one as most system administrators have found out the hard way once allocate space to a drive it is not easy to remove it. LVM makes it easy but if they are not using LVM you have to shrink filesystem, manually respecify the partition boundaries and if you mis type the starting block or end block you can corrupt the entire partition. Often times most places I've worked at it's an unwritten rule to expand but to never shrink a drive due to risks and complexity involved.