Troubleshooting the form-factor migration from v2018
Troubleshoot problems with migrating from v2018 to v10 on a different form factor.
Topics:
- Script help
- Restarting migration
- Factory reset of portal subsystem
- Avoid error when a gateway is already registered to another API manager
Script help
You can access help for all the migration scripts by using the
--help
argument:python3 <script_file_name> --help
Restarting migration
On the target system, if the
register_gateway_portals_in_target.py
,
update_to_new_portals.py
, or update_to_new_gateways.py
scripts
fail, run the load script 3
again, with the -reset_gateway_portal
flag as
shown:python3 load_v2018_data_to_v10.py ... -reset_gateway_portal
This resets
the portals and deletes the gateway pods. Note: If you deleted the data directory after you
registered the Gateways or Portals, but want to use the same target API Connect system that you
already installed, then extract the data again:
Factory reset of portal subsystem
The migration load script with
-reset_gateway_portal
does a factory reset of
your portal subsystems. Portals can also be factory reset by following these steps: - Log in to the portal
www
podadmin
container:kubectl exec -it <portal www pod> -c admin -n <apic namespace> -- bash
- Run the command:
curl -X DELETE -k --cert /etc/nginx/ssl/portal-director-client-both.pem https://localhost:3009/v2/portal/factory-reset
- Use the
list_sites
command to check that all sites are deleted. - Check health of the Portal subsystem.
Avoid error when a gateway is already registered to another API manager
Error
messages
Error: An error occurred communicating with the gateways subsystem at 'some_url' (status: 400, response: '"Unable to perform initial registration for API Management.
Error: The API Connect Gateway Service is already registered to another API Manager instance"
To fix this first try restarting the gateways, or if you are using Gateway appliances, restart
them. If the problem persists, reload the v2018 data with the
load_v2018_data_to_v10.py
script and repeat the remaining steps of the migration
process, starting with Step 5 in Restoring the v2018 data to the v10 target deployment.