Upgrading Developer Portal subsystem from 10.0.1.1-eus to the latest 10.0.1.x-eus
Upgrade the Developer Portal subsystem from 10.0.1.1-eus to the latest 10.0.1.x-eus version by completing configuration, deployment, and restoration steps.
About this task
The upgrade process uses the same project directory as you used on version 10.0.1.1-eus. The
configuration file is called
Deploy the Developer Portal subsystem for the latest 10.0.1.x-eus, and restore the Developer Portal data from a backup.
For more info, see Automatic shortening of subsystem names with greater than 63 characters (10.0.1.1-eus upgrade only).
apicup subsys list
- Obtain IBM® API Connect <version> Developer Portal for VMware from Fix Central, as described in Upgrading subsystems from 10.0.1.1-eus to the latest 10.0.1.x-eus on VMware.
- The configuration in your project directory should be complete. Optionally, you can
review the contents of
apiconnect-up-v10.yml. Since you are using the same project directory as used previously, the configuration properties for the subsystem should already have values set.
- Before deploying the latest 10.0.1.x-eus OVA, shutdown your existing v10 VMs but do not
Note: You may need to rename the old VM after shutting it down to not conflict with the latest v10 replacement you will deploy.
Create your ISO file.
apicup subsys install port --out portplan-out
--outparameter and value are required. In this example, the ISO file is created in the myProject/portplan-out directory.
- Deploy the file into the VM. See Deploying the Developer Portal subsystem OVA file.
- Verify the deployment: See Verifying deployment of the Developer Portal subsystem.
- Restore Portal using the backup taken on version 10. See Restoring the Developer Portal subsystem.
- Confirm the restore has completed successfully:
apicup subsys health-check <portal_subsystem_name>When no problems are detected, the health-check commands returns silently with a
0return code.Important: If the health check command states that a reboot is required, you must ensure that all Portal sites have been upgraded first before performing the reboot. To check that the Portal sites have upgraded, inspect the
statevalues for each site. The sites should all be in
INSTALLEDstate, and have
platformequal to the new platform that you can identify with
platforms:list. Note that there will be two platforms present in the list while the site upgrades are happening. There should be only one
platformafter they have completed. To check that the Portal sites were upgraded:
- Obtain the portal service id and
apic portal-services:get -o admin -s <management_server_endpoint> \ --availability-zone availability-zone-default <portal-service-name> \ --output - --format json
- List the
apic --mode portaladmin sites:list -s <management_server_endpoint> \ --portal_service_id <portal_service_id_from_above_command> \ --portal_service_endpoint <portal_service_endpoint_from_above_command> \ --format json
Any sites currently upgrading will be listed as
UPGRADING. Once all sites have finished upgrading they should have the
INSTALLEDstatus and the new platform version listed.
See also: apic sites:list and Using the
- After all sites are in
INSTALLEDstate and have the new platform listed, run:
apic --mode portaladmin platforms:list -s <management_server_endpoint> \ --portal_service_id <portal_service_id_from_above_command> \ --portal_service_endpoint <portal_service_endpoint_from_above_command> \ --format json
The new version of the platform should be the only platform listed.
See also: apic platforms:list and Using the
- Obtain the portal service id and endpoint: