Generate migration configuration

The utility used in this process is included in the ambari-infra-solr-client package. This package must be upgraded before the utility can be run. To do this:

SSH into a host that has an Infra Solr Instance installed on it. You can locate this host by clicking Hosts on the Ambari Web UI. Click on the Filter icon and type Infra Solr Instance: All to find each host that has an Infra Solr Instance installed on it.
Upgrade the ambari-infra-solr-client package.
- yum clean all
- yum upgrade ambari-infra-solr-client -y
For Ubuntu18:
- apt-get clean all
- apt-get install -y ambari-infra-solr-client
You can now proceed to configuring and running the migration tool from the same host. Run the following commands as root, or as a user with sudo access: Export the variable that will hold the full path and filename of the configuration file that is generated in the next step.
```
export CONFIG_INI_LOCATION=ambari_solr_migration.ini 
```
Run the migrationConfigGenerator.py script, located in the /usr/lib/ambari-infra-solr-client/ directory, with the following parameters:
--ini-file $CONFIG_INI_LOCATION

This is the previously exported environmental variable that holds the path and filename of the configuration file that will be generated.

--host=ambari.hortonworks.local

This should be the hostname of the Ambari Server.

--port=8080

This is the port of the Ambari Server. If the Ambari Server is configured to use HTTPS, use the HTTPS port and add the -s parameter to configure HTTPS as the communication protocol.

--cluster=cl1

This is the name of the cluster that is being managed by Ambari. To find the name of your cluster, look in the upper right and corner of the Ambari Web UI, just to the left of the background operations and alerts.

--username=admin

This is the name of a user that is an Ambari Admin.

--password=admin

This is the password of the user.

--backup-base-path=/my/path

This is the location where the backed up data is stored. Data is backed up to this local directory path on each host that is running an Infra Solr instance in the cluster. So, if you have 3 Infra Solr server instances and you use --backup-base-path=/home/solr/backup, this directory is created on all 3 hosts and the data for that host is backed up to this path.

If you are using a shared file system that is mounted on each Infra Solr instance in the cluster, use the --shared-drive parameter instead of --backup-base-path. The value of this parameter should be the path to the mounted drive that is used for the backup. When this option is chosen, a directory is created in this path for each Ambari Infra Solr instance with the backed up data. For example, if you had an NFS mount /export/solr on each host, you would use --shared-drive=/exports/solr. Only use this option if this path exists and is shared amongst all hosts that are running the Ambari Infra Solr.

--java-home=/usr/jdk64/jdk1.8.0_112

This should point to a valid Java 1.8 JDK that is available at the same path on each host in the cluster that is running an Ambari Infra Solr instance.

If the Ranger Audit collection is being stored in HDFS, add the parameter, --ranger-hdfs-base-path.

The value of this parameter should be set to the path in HDFS where the Solr collection for the Ranger Audit data has been configured to store its data.

Example:--ranger-hdfs-base-path=/user/infra-solr

Example Invocations:
If using HTTPS for the Ambari Server:
```
/usr/bin/python /usr/lib/ambari-infra-solr-client/migrationConfigGenerator.py \
--ini-file $CONFIG_INI_LOCATION \
--host=c7401.ambari.apache.org \
--port=8443 -s \
--cluster=cl1 \
--username=admin \
--password=admin \
--backup-base-path=/home/solr/backup \
--java-home=/usr/jdk64/jdk1.8.0_112 
```
If using HTTP for the Ambari Server:
```
/usr/bin/python /usr/lib/ambari-infra-solr-client/migrationConfigGenerator.py \
--ini-file $CONFIG_INI_LOCATION \
--host=c7401.ambari.apache.org \
--port=8080 \
--cluster=cl1 \
--username=admin \
--password=admin \
--backup-base-path=/home/solr/backup \
--java-home=/usr/jdk64/jdk1.8.0_112 
```
Ensure the script generates cleanly and there are no yellow warning texts visible. If so, review the yellow warnings.