New Contributor
Posts: 2
Registered: ‎08-25-2017

Clean or remove local state created by cloudera-director bootstrap, howto?



We are trying to automate the CDH5.12 installation through ansible and cloudera-director bootstrap. The ansible playbook will call "cloudera-director bootstrap" to start a new cluster.


A problem with this approach is that everytime "cloudera-director bootstrap" will check if there is a local state. If there is local state, the cloudera-director will pause and ask for user intervention (either start from scratch or resume). But this will fail the ansible process which is to fully automate the CDH installation.


I tried to clear /var/lib/cloudera-director* as well as /etc/cloudera-director* but non of these will allow me to remove the local state.


Any idea where the cloudera-director will store the local state and how we can remove it or bypass the local state check? I am really newbie to cloudera director and sorry if silly question asked.


Thanks for reading.





Cloudera Employee
Posts: 69
Registered: ‎10-28-2014

Re: Clean or remove local state created by cloudera-director bootstrap, howto?



The Director standalone client will create a H2 database file for each conf file you use. This will be co-located with the conf file and named by the conf file. 


For example if your conf file is:


The database file should be:



This state file is saved so that you can later terminate the deployment and cluster with the Director standalone client. You can delete this file if you have already terminated the deployment and cluster and no longer need the state.


As an alternative to clearing the state, you can use the "lp.bootstrap.resume" property for non-interactive execution.

$ cloudera-director bootstrap <filename.conf> --lp.bootstrap.resume=RESTART 

Valid values for "lp.bootstrap.resume" are INTERACTIVE, RESUME, and RESTART. INTERACTIVE is the default.


Since you are new to Director, I'd like to point you to our documentation describing the differences between using the server and the standalone client. We generally recommend using the server rather than the standalone client for the additional cluster management capabilities, but this of course dependent upon your use case.