Fixing numbered list formatting

Author: JasonWHowell

articles/azure-databricks/howto-regional-disaster-recovery.md

@@ -22,7 +22,7 @@ The Databricks control plane manages and monitors the Databricks workspace envir
 ![Databricks control plane architecture](media/howto-regional-disaster-recovery/databricks-control-plane.png)
 
 One of the advantages of this architecture is that users can connect Azure Databricks to any storage resource in their account. A key benefit is that both compute (Azure Databricks) and storage can be scaled independently of each other.
- 
+
 ## How to create a regional disaster recovery topology
 
 As you notice in the preceding architecture description, there are a number of components used for a Big Data pipeline with Azure Databricks:  Azure Storage, Azure Database, and other data sources. Azure Databricks is the *compute* for the Big Data pipeline. It is *ephemeral* in nature, meaning that while your data is still available in Azure Storage, the *compute* (Azure Databricks cluster) can be terminated so that you don’t have to pay for compute when you don’t need it. The *compute* (Azure Databricks) and storage sources must be in the same region so that jobs don’t experience high latency.  
@@ -50,8 +50,8 @@ To create your own regional disaster recovery topology, follow these requirement
    > [!NOTE]
    > Any python scripts provided in this article are expected to work with Python 2.7+ < 3.x.
 
-**2. Configure two profiles.** 
-   
+2. **Configure two profiles.**
+
    Configure one for the primary workspace, and another one for the secondary workspace:
 
    ```bash
@@ -60,22 +60,24 @@ To create your own regional disaster recovery topology, follow these requirement
    ```
 
    The code blocks in this article switch between profiles in each subsequent step using the corresponding workspace command. Be sure that the names of the profiles you create are substituted into each code block.
+
    ```python
    EXPORT_PROFILE = "primary"
    IMPORT_PROFILE = "secondary"
    ```
 
    You can manually switch at the command line if needed:
+
    ```bash
    databricks workspace ls --profile primary
    databricks workspace ls --profile secondary
    ```
 
-**3. Migrate Azure Active Directory users**
+3. **Migrate Azure Active Directory users**
 
    Manually add the same Azure Active Directory users to the secondary workspace that exist in primary workspace.
 
-**4. Migrate the user folders and notebooks**
+4. **Migrate the user folders and notebooks**
 
    Use the following python code to migrate the sandboxed user environments, which include the nested folder structure and notebooks per user.
 
@@ -86,23 +88,23 @@ To create your own regional disaster recovery topology, follow these requirement
 
    ```python
    from subprocess import call, check_output
-   
+
    EXPORT_PROFILE = "primary"
    IMPORT_PROFILE = "secondary"
-   
+
    # Get a list of all users
    user_list_out = check_output(["databricks", "workspace", "ls", "/Users", "--profile", EXPORT_PROFILE])
    user_list = user_list_out.splitlines()
-   
+
    # Export sandboxed environment (folders, notebooks) for each user and import into new workspace.
    # Libraries are not included with these APIs / commands.
-   
+
    for user in user_list:
      print "Trying to migrate workspace for user " + user
-   
+
      call("mkdir -p " + user, shell=True)
      export_exit_status = call("databricks workspace export_dir /Users/" + user + " ./" + user + " --profile " + EXPORT_PROFILE, shell=True)
-     
+
      if export_exit_status==0:
        print "Export Success"
        import_exit_status = call("databricks workspace import_dir ./" + user + " /Users/" + user + " --profile " + IMPORT_PROFILE, shell=True)
@@ -112,11 +114,11 @@ To create your own regional disaster recovery topology, follow these requirement
          print "Import Failure"
      else:
        print "Export Failure"
-   
+
    print "All done"
    ```
 
-**5. Migrate the cluster configurations**
+5. **Migrate the cluster configurations**
 
    Once notebooks have been migrated, you can optionally migrate the cluster configurations to the new workspace. It's almost a fully automated step using databricks-cli, unless you would like to do selective cluster config migration rather than for all.
 
@@ -169,7 +171,7 @@ To create your own regional disaster recovery topology, follow these requirement
    print "All done"
    ```
 
-**6. Migrate the jobs configuration**
+6. **Migrate the jobs configuration**
 
    If you migrated cluster configurations in the previous step, you can opt to migrate job configurations to the new workspace. It is a fully automated step using databricks-cli, unless you would like to do selective job config migration rather than doing it for all jobs.
 
@@ -233,15 +235,15 @@ To create your own regional disaster recovery topology, follow these requirement
    print "All done"
    ```
 
-**7. Migrate libraries**
+7. **Migrate libraries**
 
    There's currently no straightforward way to migrate libraries from one workspace to another. Reinstall those libraries into the new workspace. Hence this step is mostly manual. This is possible to automate  using combination of [DBFS CLI](https://github.com/databricks/databricks-cli#dbfs-cli-examples) to upload custom libraries to the workspace and [Libraries CLI](https://github.com/databricks/databricks-cli#libraries-cli).
 
-**8. Migrate Azure blob storage and Azure Data Lake Store mounts**
+8. **Migrate Azure blob storage and Azure Data Lake Store mounts**
 
    Manually remount all [Azure Blob storage](https://docs.azuredatabricks.net/spark/latest/data-sources/azure/azure-storage.html) and [Azure Data Lake Store (Gen 1)](https://docs.azuredatabricks.net/spark/latest/data-sources/azure/azure-datalake.html) mount points using a notebook-based solution. The storage resources would have been mounted in the primary workspace, and that has to be repeated in the secondary workspace. There is no external API for mounts.
 
-**9. Migrate cluster init scripts**
+9. **Migrate cluster init scripts**
 
    Any cluster initialization scripts can be migrated from old to new workspace using the [DBFS CLI](https://github.com/databricks/databricks-cli#dbfs-cli-examples). First, copy the needed scripts from "dbfs:/dat abricks/init/.." to your local desktop or virtual machine. Next, copy those scripts into the new workspace at the same path.
 
@@ -253,7 +255,7 @@ To create your own regional disaster recovery topology, follow these requirement
    dbfs cp -r old-ws-init-scripts dbfs:/databricks/init --profile secondary
    ```
 
-**1. Manually reconfigure and reapply access control.**
+10. **Manually reconfigure and reapply access control.**
 
    If your existing primary workspace is configured to use the Premium tier (SKU), it's likely you also are using the [Access Control feature](https://docs.azuredatabricks.net/administration-guide/admin-settings/index.html#manage-access-control).