If 'about-to-be-converted' HA node will already be attempted to be startup'ed once, the admin-access user check will fail due to the fact that it is not created in the database (and will not be created) since Artifactory will not bootstrap the creds.bootstrap file to Access. The log entry entry for this:
This happens only on the first startup.
This scenario can happen to onboarding customers, or those who have accidentally startup'ed a standalone instance (before making it a node).
Steps to reproduce:
1. Startup an HA node with Derby
2. Convert the node to HA (add ha-node.properties & db.properties if needed)
3. Startup Artifactory and observe the below message (Could not find the new Access admin user. Sleeping for 2 seconds and retrying):
This will persist for 90 seconds until Artifactory gives up. In the background there's a SQL query that does existence check for the access-admin.
The same thing will not happen to a single instance - it will always try to generate a new admin user if needed.
The suggestion is to make a similar resilient improvement for HA as well.
1. Bootstrap the admin-access user so it will be re-registered in the Database: https://www.jfrog.com/confluence/display/ACC/Configuring+Access#ConfiguringAccess-PreparingTheCredentialsFile
and also delete the $ARTIFACTORY_HOME/etc/security/access/keys/access.creds file
2. Delete the adminToken either from the config descriptor or the file system (above 6.4.0 it is on the file system under $ARTIFACTORY_HOME/etc/security/access/access.admin.token) and restart the cluster (each node holds an access HA "communication" token in it's memory after reach start).
3. Restart the cluster to avoid propagation errors.