Support Questions

Find answers, ask questions, and share your expertise
Announcements
Celebrating as our community reaches 100,000 members! Thank you!

Director 2.8 and deprecation of standalone client

avatar
Rising Star

I would like some clarification on the reported deprecation of the Director client's "standalone" functionality in version 2.8 and beyond.

 

We currently use Cloudera Director 2.7 to bootstrap client environments.  To do this, we use the standalone client on Jenkins to execute the bootstrap-remote command, which makes a call out to our Director server.  We would like to continue using Jenkins because our Cloudera deployments are simply part of the multi-stage client deployment job. 

 

Will the bootstrap-remote option be removed in future releases as part of this deprecation?

1 ACCEPTED SOLUTION

avatar
Super Collaborator

Hi dturner,

 

The bootstrap-remote command will remain in Cloudera Director for the foreseeable future. What we're planning to remove is the bootstrap command, without the "-remote" bit at the end. The bootstrap-remote command communicates with a Director server, while the bootstrap command does all of the work locally within the client. We call using the non-remote bootstrap command using the client in "standalone" mode, and it's those non-remote commands that are going away.

 

We realized that having such similar client commands was pretty confusing. For example, some folks would use the bootstrap command (non-remote) to spin up a cluster, but then be surprised that their Director server elsewhere wouldn't know about it.

 

Overall, it's just better to use the server and remote client commands anyway. For one thing, the server API and Java / Python SDKs are available for servers, but don't work for clusters created from the "standalone" client bootstrap command.

 

I hope that helps clear up the confusion.

View solution in original post

2 REPLIES 2

avatar
Super Collaborator

Hi dturner,

 

The bootstrap-remote command will remain in Cloudera Director for the foreseeable future. What we're planning to remove is the bootstrap command, without the "-remote" bit at the end. The bootstrap-remote command communicates with a Director server, while the bootstrap command does all of the work locally within the client. We call using the non-remote bootstrap command using the client in "standalone" mode, and it's those non-remote commands that are going away.

 

We realized that having such similar client commands was pretty confusing. For example, some folks would use the bootstrap command (non-remote) to spin up a cluster, but then be surprised that their Director server elsewhere wouldn't know about it.

 

Overall, it's just better to use the server and remote client commands anyway. For one thing, the server API and Java / Python SDKs are available for servers, but don't work for clusters created from the "standalone" client bootstrap command.

 

I hope that helps clear up the confusion.

avatar
Rising Star

Bill, 

 

Thank you for the clarification.