A single Cloudera Director instance can have multiple environments, potentially spanning multiple cloud providers or regions. Each environment is configured with a specific cloud provider and region. A single environment can have multiple deployments, each corresponding to a single Cloudera Manager instance. Each Cloudera Manager instance can manage multiple clusters.   The only requirement is that Cloudera Director can reach the hosts it creates via SSH. If you use Cloudera Director to manage clusters within a single region, you can potentially have all communication be on the private IP addresses of the instances. If you use Cloudera Director to manage clusters in a different cloud provider or region, you will either have to do special networking (e.g. VPN) to gain access to the private IP addresses, or you will have to permit SSH access on the public IP address, which has security implications.   ... View more

Due to a bug, the UI is displaying only properties marked as sensitive, despite the fact that other properties are required. As a workaround, you can use the API console to update the credentials.   Go to the Environments section of the API console. Open the Get /api/v5/environments section, and click Try it out! to list the environments. Copy the environment name for the environment in which you want to update the credentials. Open the Get /api/v5/environments/{name} section, paste the environment name into the name parameter box, and click Try it out! to display the environment. Copy the config block of the JSON (should have keys like tenantId, etc.). You only want the curly braces and content, not the "config": key. Open the Put /api/v5/environments/{name}/provider/credentials section, paste the JSON block, remove the line containing the region (*see below for an explanation), and replace the REDACTED value of clientSecret with the new value. Click Try it out! to update the credentials. On success, you should get a 202 response code. For other response codes, check the error message and look in the Director server log if necessary.   * The region key is not a credentials configuration key. You can see all the valid credentials configuration keys by opening the provider-metadata section of the API console, opening the Get /api/v5/metadata/providers/{providerId} section, entering azure in the providerId parameter box, clicking Try it out! to list the metadata, and finding the credentialsProperties JSON block. The configKey field of the entries in there are the valid credentials property configuration keys. ... View more

Director itself doesn't care whether the AMI uses HVM or PV, but EC2 instance types are often only compatible with a single virtualization type. As you say, Amazon recommends HVM for the R3 instance type.   Here's a pretty good blog post on virtualization types: http://cloudacademy.com/blog/aws-ami-hvm-vs-pv-paravirtual-amazon/   That describe-images command is just an example, and you can change the parameters to suit the particular AMI details you are looking for.   ... View more

I'm sorry you don't have a database backup, as Director 1.5.x won't be able to start on a database that has already been upgraded to 2.1. To start fresh, you should install Director on a new instance, then either use the new Director, or shut down both the new Director and the existing Director 2.1, and replace the database on the existing one with the database from the new one. Of course you won't have any useful information after this process.   Given that this route will result in the loss of your data, I can suggest two unsupported paths that *might* preserve your data. First shut down your existing Director instance and back up its database, then open the database using H2 tools.   Option 1 is to look in the SERVER_CONFIGS table for an entry with the key refreshDeploymentsOnStart, and set its value to false, then try starting Director. If it starts successfully, terminate the problem deployment using the Director UI, then shut down Director, edit the database again, set the refreshDeploymentsOnStart back to true, and start the server again. If it starts successfully, you should be good to go.   If Option 1 doesn't work, Option 2 is to delete the problem deployment from the DEPLOYMENTS table. Because the data is encrypted, you won't know which row is the correct one to delete, but you can try each one successively, attempting to start the server after each one, and restoring the db from backup if it still won't start. If the CM instance that you deleted outside of Director had one or more clusters that you also deleted manually outside of Director, you may also have to remove rows from the CLUSTERS table.   Good luck!   ... View more

FYI, the AWS plugin for Director is open source, so it is possible that you could build a custom version of the plugin that satisfies your requirements: https://github.com/cloudera/director-aws-plugin   ... View more