About Darren

Darren · ‎01-03-2017

The balancer role just tells CM which host the balancer command should be executed from. Running it via API is a bit weird. You start the role to run the balancer.

Darren · ‎12-21-2016

If you have a role called "SecondaryNameNode", then that's incorrect. This is a very confusing name for the role in Hadoop. The SecondaryNameNode is only used in non-HA scenario. In HA, you have multiple (regular) NameNode roles defined. HDFS HA, when properly configured, will have a nameservice. There are many other steps though. The HDFS HA setup process is particularly complicated, so if you can return to a normal non-HA state, then get the wizard to work, it's much better. What issue did you hit with the Enable NameNode HA wizard? If you have a trial or enterprise license, you can use the config history page to help identify what changes you made since you had a normal, non-HA state, which can help you revert your changes.

Darren · ‎12-21-2016

If you look at the Oozie config page, and search for load balancer, is that configured correctly? Did you set up HA for Oozie using the CM wizard? https://www.cloudera.com/documentation/enterprise/latest/topics/cdh_hag_oozie_ha.html

Darren · ‎12-20-2016

Please ignore the permission error on supervisor.conf. The script that failed to update that file doesn't actually need to target that file. A future version of Cloudera Manager has updated the code to not log this spurrious error. You may also want to revert the permissions to supervisor.conf to not be world-readable. What does the end of the stderr log say? Did you check the role logs for your FC for a relevant error message?

Darren · ‎09-27-2016

Oh sorry, I misunderstood. When you add a host, CM will automatically distribute all parcels to that host and activate it so it matches all other hosts in the cluster.

Darren · ‎09-27-2016

Read about parcel lifecycles here: https://www.cloudera.com/documentation/enterprise/latest/topics/cm_ig_parcels.html#concept_k1c_wgx_pn All activated parcels are already downloaded and distributed.

Darren · ‎09-27-2016

CM will automatically de-activate conflicting parcels, which is why you didn't need to de-activate 5.5.1 first. It would be a burden on the user to identify and de-activate all conflicting parcels, and this is by design. The CM UI will show the upgrade option when you are trying to activate a CDH parcel of a higher version. This will take you through the upgrade wizard, which is generally what you want. In your case, you don't really want the upgrade wizard and can use the API to directly activate 5.5.1 again. If your API script should never be run when CDH is already installed, you can add a check to your script to validate that requirement. Rather than trying to test with a single host within a cluster, you can make a test cluster with a single host and try out your API script.

Darren · ‎09-27-2016

Hi Keagles, CM always distributes parcels to the entire cluster. It's generally much easier to manage your cluster when all hosts are running the same software, and the overhead of distributing and storing these binaries is generally very small compared to the real cluster activity and size of your real data. You can easily deactivate, undistribute, and delete parcels if you don't like the change you made. You can also test things out by just downloading the parcel via the API, then checking in the CM UI that you got the right one.

Darren · ‎09-07-2016

Hi, CM will continually re-try client config deployment. This is helpful in particular if the host is temporarily not available and comes online later. It makes it easier for the administrator to reason about the state of client configs, so you don't have to worry about re-executing the command on a few random hosts that weren't operational at the time of deploy. So the retries are intended. Ideally, the deploy scripts should be so simple that they can't really fail. If you're just debugging your changes, then you can stop the CM agent (service cloudera-scm-agent stop) on that host to stop the wiping / retry logic and make it easier to debug. Thanks, Darren

Darren · ‎08-18-2016

I see. Single User Mode is a CM server setting. There's no way for a CSD or Parcel to change a CM server setting, but it can be set via the REST API. If you are wrapping the CM installation and want to turn on single user mode, you can also make that REST call, but keep in mind there's quite a few other things you'd need to handle as discussed in the documentation you already linked (http://www.cloudera.com/documentation/enterprise/latest/topics/install_singleuser_reqts.html).

Online	Offline
Last Visited	‎05-21-2019 01:27 PM

Member Since	‎07-30-2013 10:59 AM
Last Visited	‎05-21-2019 01:27 PM
Posts	509
Kudos received	112

Cloudera Community

Re: Install using CM of Datanodes with different n...

Re: Cloudera API doesn't return any roles for a ho...

Re: Stopping selected roles from Service action me...

Re: CSD Role with Multiple SSLServers

Re: CSD - SSLServer Paramaters

Re: HDFS Balancer isn't running by itself

Re: Fail to start HDFS FAILOVERCONTROLLER (FC) - s...

Re: How to merge oozie HA HTTP keberos principals ...

Re: Fail to start HDFS FAILOVERCONTROLLER (FC) - s...

Re: How to use CM API to distribute parcel to a ho...

Re: How to use CM API to distribute parcel to a ho...

Re: How to use CM API to distribute parcel to a ho...

Re: How to use CM API to distribute parcel to a ho...

Re: Deploy Client Config retries infinitely after ...

Re: Running a CSD as a particular user while using...