Well, I’m really baffled by this. Restarting the agents before installing a
cluster fixes the issue as well? So it seems like after agents are installed
they are not able to make connections from python without getting a 403
forbidden until they are restarted at least once. Is it possible to get
If I pass this configuration in to YARN on HDP2.2 using Ambari 2.0:
"yarn.timeline-service.leveldb-timeline-store.path":
'hdfs:///apps/yarn/timeline'
It spins forever waiting to set up the HDFS paths for me. I like that it tries
to auto-create the folder for me, but maybe there's an order-of-o
Hi Loïc,
I am sorry it took so long to get back to you. I didn't see your question until
just now.
For now, Ambari needs to be on a host in the cluster. We hope to fix this
requirement soon, but at least through Ambari 2.1, this requirement will stand.
So if you have a cluster such that the ho
Disclosure, I used HDP 2.2.0.0 documenation to upgrade from HDP 2.1 and
then followed with much better HDP 2.2.4.2 documenation. However, I did not
find steps to fix the issue I'm about to describe. I confirm that manual
install has the right configuration, it just doesn't take affect during
upgrad
Hey all,
I have a cluster with HDP 2.1.7 stack which I recently upgraded from Ambari
1.6.1 to 2.0.0. I have a computer in my cluster that I need to decommission.
I have been moving away all the master components from this machine. The last
remaining is the History Server however it seems that
Looks like yarn.resourcemanager.store.class defaulted to
org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore
Ambari should probably not set that unless there is a zookeeper_server in the
cluster.
Greg
From: Greg mailto:greg.h...@rackspace.com>>
Reply-To: "user@ambari.apache.o
The YARN resource manager keeps crashing in Ambari 2.0 + HDP 2.2.4.2 clusters
for me. The error log indicates that it can't connect to zookeeper, which
makes sense since I didn't provision zookeeper as I don't use it. I found the
relevant settings in the Ambari UI:
yarn.resourcemanager.zk-add
Hi Jonathan,
Additional information : the restart does not have to be necessarily AFTER the
cluster have been deployed using a Blueprint. Restarting the ambari-agent
before using a blueprint to deploy the cluster make a perfectly clear cluster,
without the 11 Warnings/Errors I mentioned in my p
