Hi @ManjuN ,   NoClassDefFoundError Is usually seen when required jar is missing. In this case atlas migration script is looking for a jar which contains class "com/tinkerpop/blueprints/Graph". This class definition is available in blueprints-core-2.6.0.jar which is available on HDP-2.6.x.     # jar -tf /usr/hdp/2.6.<version>/atlas/server/webapp/atlas/WEB-INF/lib/blueprints-core-2.6.0.jar | grep -i "com/tinkerpop/blueprints/Graph" com/tinkerpop/blueprints/Graph.class com/tinkerpop/blueprints/GraphFactory.class com/tinkerpop/blueprints/GraphQuery.class       In your case, you are running a migration script from "3.1.0.0-78" directory and that is the reason you are getting NoClassDefFoundError.     python /usr/hdp/3.1.0.0-78/atlas/tools/migration-exporter/atlas_migration_export.py -d /atlas_metadata       Steps in the document needs to be performed only if you are upgrading your cluster from 2.6.x to 3.0+ version, because In HDP-3.0+, Apache Atlas uses the JanusGraph graph database to store metadata objects whereas in earlier versions, Atlas used the Titan graph database for metadata storage.   The document says, "Before upgrading HDP and Atlas, perform the following steps on the HDP-2.x cluster".   If you are performing this step during a major upgrade (from HDP-2.6.x to HDP3.0+ or 2.6.5 to HDP-7.x), kindly run atlas_migration_export.py script from 2.6.x path. For minor versions, this step is not required. ... View more

Following KB can be used to delete users/groups in bulk   https://community.cloudera.com/t5/Community-Articles/Remove-AD-LDAP-accounts-from-Ambari-using-REST-API/tac-p/244196   ... View more

In case ambari API doesn't help. You can use following SQL queries to abort hung/queued/pending operations directly from ambari database.   1) Stop Ambari-Server   ambari-server stop   2) Take backup of ambari database before making any changes to ambari db 3) Check IN_PROGRESS, QUEUED and PENDING operations.   ambari=> select task_id,role,role_command from host_role_command where status='IN_PROGRESS'; ambari=> select task_id,role,role_command from host_role_command where status='QUEUED' limit 100; ambari=> select task_id,role,role_command from host_role_command where status='PENDING';   4) Abort Operations   ambari=> update host_role_command set status='ABORTED' where status='QUEUED'; ambari=> update host_role_command set status='ABORTED' where status='PENDING'; ambari=> update host_role_command set status='ABORTED' where status='IN_PROGRESS';   5) Start ambari-server   ambari-server start       ... View more

For secured/kerberized cluster, we may need to push kdc admin credentials by creating a temp credential store before deleting Ranger Admin component   ADD KDC CREDENTIALS: # curl -ivk -H "X-Requested-By: ambari" -u $AMBARI_USER:$AMBARI_PASSWD -X POST -d '{ "Credential" : { "principal" : "admin/admin@REALM", "key" : "hadoop", "type" : "temporary" } }' "$AMBARI_URL/api/v1/clusters/$CLUSTER_NAME/credentials/kdc.admin.credential" GET CREDENTIALS # curl -ivk -H "X-Requested-By: ambari" -u $AMBARI_USER:$AMBARI_PASSWD -X GET "$AMBARI_URL/api/v1/clusters/$CLUSTER_NAME/credentials/kdc.admin.credential"   ... View more

@Yan Liu this isn't an issue to worry about. Ambari keeps checking the NN status until it detects that the NN is out of safemode. It usually takes sometime because of the reasons mentioned above. ... View more

Because Ambari keeps trying to get the safe mode status of namenode. And when it detects that the safe mode is OFF (grep 'Safe mode is OFF'), it shows Namenode started. Namenode usually takes some time to come out of safemode, Because: During Namenode startup, the NameNode must complete certain actions before it can serve client requests: Read file system metadata from the fsimage file. Read edit logs and apply logged operations to the file system metadata. Write a new checkpoint (a new fsimage consisting of the prior fsimage plus the application of all operations from the edit logs). Remain in safe mode until a sufficient number of blocks have been reported by datanodes. In some situations, these actions can take a long time to complete. ... View more

This issue is usually seen when user wan't removed properly from Ranger db and some information is still available in user tables. For example in above situation it might be possible that 'user1' is not available in x_user table but its still part of other user tables such as x_portal_user, x_portal_user_role, x_user_module_perm, x_auth_sess etc. Perform below steps to resolve this issue. Verify whether problematic user is available in other tables MariaDB [ranger]> select * from x_user where user_name = 'user1'; MariaDB [ranger]> select id from x_portal_user where login_id = 'user1';  +----+ | id | +----+ | 44 | +----+ MariaDB [ranger]> delete from x_portal_user_role where id = 44;  MariaDB [ranger]> delete from x_user_module_perm where user_id = 44; MariaDB [ranger]> delete from x_auth_sess where user_id = 44; MariaDB [ranger]> delete from x_portal_user where id = 44;  To get all such user's MariaDB [ranger]>  select * from x_portal_user_role where id not in (select id from x_user); MariaDB [ranger]>  select * from x_user_module_perm where user_id not in (select id from x_user); MariaDB [ranger]>  select * from x_auth_sess where user_id not in (select id from x_user); MariaDB [ranger]>  select * from x_portal_user where id not in (select id from x_user); Remove users which are not part of x_user table but available in other tables MariaDB [ranger]>  delete from x_portal_user_role where id not in (select id from x_user);  MariaDB [ranger]>  delete from x_user_module_perm where user_id not in (select id from x_user);  MariaDB [ranger]>  delete from x_auth_sess where user_id not in (select id from x_user);  MariaDB [ranger]>  delete from x_portal_user where id not in (select id from x_user);  Restart usersync process ... View more

it needs to be updated in ambari.properties file ... View more