Important Notes About Cloudera Director and Azure

• Changing the instance type of an already-deployed VM is not supported in Azure.
• Changing the instance type of a VM through a tool external to Cloudera Director is not supported in Azure. You cannot, for example, use the Azure Portal to change the instance type. Cloudera Director is not updated when instance type changes are made with external tools, and your cluster will show errors in Cloudera Director.

1. Turn off credential validation.
   1. ssh to the Cloudera Director server host.
   2. Locate the Azure plugin configuration file if you have one, or create a new plugin configuration file.
      1. If you already have a configuration file, it will be located at /var/lib/cloudera-director-plugins/azure-provider-version/etc/azure-plugin.conf.
      2. If there is no azure-plugin.conf file at that location, create one by running the following command:

         wget -O /var/lib/cloudera-director-plugins/azure-provider-version/etc/azure-plugin.conf
         https://raw.githubusercontent.com/cloudera/director-scripts/master/azure-plugin-config/azure-plugin.conf

   3. Edit the azure-plugin.conf file. Towards the end of the file there’s an azure-validate-credentials field. Change the value to false:

      azure-validate-credentials: false

2. Restart Cloudera Director:

   sudo service cloudera-director-server restart

3. Update the credentials in either of the following ways:
   • Using the Cloudera Director UI:
     1. Log into Cloudera Director and go to the environment whose client secret has expired.
     2. From the Add Cloudera Manager dropdown menu, select Update Environment Credentials.
     3. Put in the new client secret along with your existing settings for this environment. Existing environment settings can be found under the Details tab.
   • Using the Cloudera Director API:
     1. Log into Cloudera Director. (You must be authenticated to use the Cloudera Director API.)
     2. Go the the environments section of the API console of your Cloudera Director server (replace director-server-hostname with your own):

        http://director-server-hostname:7189/api-console/index.html#

     3. Click on the GET /api/v11/environments section, and click Try it out! to list the environments. If you are using a version of the API other than v11, this procedure will still work, but your URL will contain the version you are using in place of v11.
     4. Copy the name of the environment whose client secret has expired. Open the GET /api/v11/environments/{name} section and paste the environment name into the name parameter box, and click Try it out! to display the environment details.
     5. Copy the config portion of the JSON block including the curly braces but excluding the "config" string. It should similar to the example below. You might have different fields and values, but clientSecret should be there. If the clientSecret field is not there, check to be sure you are using the correct API.

        {
            "tenantId": "[...]",
            "region": "eastus2",
            "azureCloudEnvironment": "azure",
            "clientSecret": "REDACTED",
            "subscriptionId": "[...]",
            "clientId": "[...]"
        }
        

     6. Open the PUT /api/v11/environments/{name}/provider/credentials section. Note that there is /provider/credentials in the path - it is NOT the PUT /api/v11/environments/{name} section.
     7. Paste in the whole JSON block, including all fields and the surrounding curly braces, and then edit the JSON block:

        • Remove the "region" line.

        • Replace the "REDACTED" portion of "clientSecret": "REDACTED" with your new client secret.

     8. Click Try it out! again to update the credentials. On success, you should get a 202 response code. If you get a 400 Bad Request, check the Cloudera Director logs for full details. Also, check that you have not made any of the following common mistakes:

        • a. Using PUT /api/v11/environments/{name} instead of PUT /api/v11/environments/{name}/provider/credentials (note the /provider/credentials in the path).

          This causes the following response:

             "status": 400,
             "error": "Bad Request",
             "exception":
          "org.springframework.http.converter.HttpMessageNotReadableException",
             "message": "Bad Request"

        • b. Improperly formatted JSON. This causes the following response:

             "status": 400,
             "error": "Bad Request",
             "exception":
          "org.springframework.http.converter.HttpMessageNotReadableException",
             "message": "Bad Request"

        • c. Forgetting to remove the "region" line. This causes the following response:

             "status": 400,
             "error": "Bad Request",
             "exception":
          "com.cloudera.launchpad.api.common.EnvironmentsResource$UnsupportedEnvironmentUpdateException",
             "message": "Unsupported environment update request"

4. Turn on credential validation. In this step, you undo what you did in the beginning:
   • If you did not have an azure-plugin.conf file initially, delete the file now.
   • If there was a file initially, then change azure-validate-credentials in your azure-plugin.conf back to true:

     azure-validate-credentials: true

5. Restart Cloudera Director:

   sudo service cloudera-director-server restart

6. Verify the fix.
   1. Tail the logs on the Cloudera Director host:

      tail -f /var/log/cloudera-director-server/application.log

   2. Log into the Cloudera Director UI and go to the environment whose client secret was previously expired.
   3. If there are no errors with credential validation in the Cloudera Director UI or in the logs, then the new client secret has been applied.

Skipping Azure credential validation with Azure backend.