Support Questions
Find answers, ask questions, and share your expertise
Alert: Welcome to the Unified Cloudera Community. Former HCC members be sure to read and learn how to activate your account here.

Director cannot create EC2 - Insufficient number of instances available

Solved Go to solution

Re: Director cannot create EC2 - Insufficient number of instances available

Master Collaborator

Yes, the whole cluster (CM and the all the CDH nodes) were sucesfully deployed. But not by the Cloudera Director Server (Web UI), because there is not possibility to load the configuration script. So I used the Cloudera Director client command line tool.


The pity thing is, that these two approaches cannot be combined. So if you deploy the cluster by the command line tool, then you loose the ability to "manage" it from the nice UI. On the other hand, deploying HA clusters with lots of custom options is not possible via UI, because there is no option to load your own configuration file.


And the last whish for Cloudera, please if you provide the wizard UI and step by step cluster provision, it would be very nice to integrate with the client tool, to provide the possibility to export the configured deployemnt to a json file. 

It took me a lot of efforts to find out, how some of the specific settings has to be configured in the template.



Regarding troubleshooting, try to look at the Cloudera Director logs. You can increase the verbosity. Basically in the log you will find many concurrent processes writing to the same log, so it needs a little work to extract just the messages related to the provision of Cloudera Manager.



Re: Director cannot create EC2 - Insufficient number of instances available

Expert Contributor

Hi Tomas79,


First, thanks for your contributions to this thread as well as your suggestions!


We do steer experienced users toward using configuration files and the bootstrap-remote CLI command vs. the UI, because the UI would get complex if we tried to add a checkbox or field or form for every Director feature into it. The Director server does have a full set of API endpoints that you can use to make updates to clusters that aren't easy or possible to do over the UI, so I recommend taking a look there. If you go to the /api-console URL for Director, there's an interactive facility for learning about the API and trying it out live.


For example, there is an API endpoint for importing a configuration file directly into the server. It's documented here:


We don't have a corresponding configuration file export API endpoint yet, but you are not the first to suggest it, so be assured that it's on our wish list. In the meantime, the API can help you if you're willing to work with that.


Director's single log is tough to navigate. Recent Director versions have added more context to lines in the log which make it feasible to filter relevant lines out. We've got some techniques documented here:


But I see room for more documentation. Specifically, at least as of 2.4:


  • Each line includes a thread ID in square brackets. The ones starting with "p-" are for pipelines, Director's internal workflows, so you can follow one of those among all the other pipelines and other asynchronous tasks within Director.
  • The fields following the thread ID are the unique (API) request ID, request method, and request URI that ultimately caused the activity being logged.

You can work with the logback.xml file for the server to change the formatting, and perhaps even route logging to multiple files for easier comprehension (another ask that we've heard).


Again, thanks for your feedback!

Don't have an account?
Coming from Hortonworks? Activate your account here