Forward Upgrade to VCF 5.0 with deviated BOM Components (higher than VCF 5.0 supported BOM)

Products

• VMware Cloud Foundation

Issue/Introduction

With async patching capabilities of VCF, users are likely to end up with the state wherein certain BOM components are patched/upgraded with higher versions than VCF supported release BOM on 5.0

Symptoms:
Users are blocked from choosing VCF 5.0 as the desired target release on the domains.

Environment

VMware Cloud Foundation 4.2.1
VMware Cloud Foundation 4.4.0
VMware Cloud Foundation 4.3.x
VMware Cloud Foundation 4.3.1
VMware Cloud Foundation 4.4.1
VMware Cloud Foundation 5.0
VMware Cloud Foundation 4.4.x
Vmware Cloud Foundation 4.5
VMware Cloud Foundation 4.2.x

Cause

LCM in product Skip upgrades has restrictions to block the forward upgrade paths unless all the BOM components on environment are lower than the target release versions

Resolution

VMware is aware of this issue and working to resolve this in a future release.

Workaround:

To perform this functionality, The user will need to run AP tool using input spec mode, or "-i", which provides an input JSON that the tool will read all of the desired patches from.

An input spec typically looks like this for a single async patch:
{
  "actions": [
    {
      "action": "enable_sddc_service_patch",
      "configuration": {
        "services": [
          {
            "sddc_manager_version": "4.3.1.1-19235535",
            "sddc_services_info": [
              {
                "name": "lcm",
                "upgrade_file": "vcf-lcm-4.3.1-19793746.pak",
                "base_version": "4.3.1-vcf4311RELEASE-19235255",
                "aliases": [
                  "4.3.1.0-19793746"
                ],
                "bundle_name": "bundle-57619"
              }
            ]
          }
        ]
      }
    },
    {
      "action": "enable_bom_patch",
      "configuration": {
        "bundles": [
          {
            "name": "bundle-61453"
          }
        ]
      }
    }
  ],
  "ap_tool_configs": null
}

This input spec contains two sections: enable_sddc_service_patch and enable_bom_patch. AP tool reads the input spec in order, and therefore first applies the SDDC manager service upgrade associated with the BOM patch in the "enable_bom_patch" section (in this case, bundle-61453). Then, it enables the BOM patch in the next section under "enable_bom_patch".

To run the workflow with multiple async patches in one, the input spec will have multiple sections similar to the example above. Let's take an example where one wants to apply:

1. NSX-T manager patch with version 3.1.3.8.0-20532384,bundle-63129,input spec URL: https://depot.vmware.com/PROD2/evo/vmw/asyncPatchSpecs/v1/bundle-63129.spec)

 

2. ESX patch, version 7.0.3-20328353, bundle-60929, input spec URL: https://depot.vmware.com/PROD2/evo/vmw/asyncPatchSpecs/v1/bundle-60929.spec)
The person who is constructing the input spec will then combine the input specs for enable_bom_patch for both patches in the order they want the patches to be applied on the environment. For example, if they want NSX-T to go before ESX, then the input spec should have that ordering of the enable_bom_patch sections. In short, order matters! If you put NSX-T first in the spec, that will become available as a bundle while ESX will be in pending. Once NSX-T is applied, then ESX will become available.

Here is an example of a combined input spec for NSX-T manager patch + ESX patch (in that order):
{
  "actions": [
    {
      "action": "enable_sddc_service_patch",
      "configuration": {
        "services": [
          {
            "sddc_manager_version": "4.3.1.1-19235535",
            "sddc_services_info": [
              {
                "name": "lcm",
                "upgrade_file": "vcf-lcm-4.3.1-19793746.pak",
                "base_version": "4.3.1-vcf4311RELEASE-19235255",
                "aliases": [
                  "4.3.1.0-19793746"
                ],
                "bundle_name": "bundle-57619"
              }
            ]
          }
        ]
      }
    },
    {
      "action": "enable_bom_patch",
      "configuration": {
        "bundles": [
          {
            "name": "bundle-63129"
          }
        ]
      }
    },
    {
      "action": "enable_bom_patch",
      "configuration": {
        "bundles": [
          {
            "name": "bundle-60929"
          }
        ]
      }
    }
  ],
  "ap_tool_configs": null
}

Here is an example of a combined input spec for ESX manager patch + NSX-T patch (in that order):
{
  "actions": [
    {
      "action": "enable_sddc_service_patch",
      "configuration": {
        "services": [
          {
            "sddc_manager_version": "4.3.1.1-19235535",
            "sddc_services_info": [
              {
                "name": "lcm",
                "upgrade_file": "vcf-lcm-4.3.1-19793746.pak",
                "base_version": "4.3.1-vcf4311RELEASE-19235255",
                "aliases": [
                  "4.3.1.0-19793746"
                ],
                "bundle_name": "bundle-57619"
              }
            ]
          }
        ]
      }
    },
    {
      "action": "enable_bom_patch",
      "configuration": {
        "bundles": [
          {
            "name": "bundle-60929"
          }
        ]
      }
    },
    {
      "action": "enable_bom_patch",
      "configuration": {
        "bundles": [
          {
            "name": "bundle-63129"
          }
        ]
      }
    }
  ],
  "ap_tool_configs": null
}
Once you have the combined input spec, you can label the input spec as input_json and pass it in using the -i option. See AP tool options for the full CLI argument.