For issue with the Bind entity you might like to look for strings
matching these messages in your debug log:
"Skipped update of {} when service state is {} and running is {}"
"Member {} of {} does not have an SSH location so will not be configured"
It also logs "updating with entities: <list>" which will indicate
whether your missing entities were ever under consideration.
Sam
On 02/02/2015 09:25, Duncan Grant wrote:
I agree, it's really annoying. The hostname resolves to "(none)" , which I
assume means there isn't one set.
I'll do some testing on the maximum size.
Ambari does a test when it starts that the hostname resolves to the
machines ip and refuses to start if it doesn't. For softlayer I currently
use the binddns entity to make the hostnames resolve, although I'm finding
this a bit hit and miss - sometimes all my entities get configured properly
and sometimes one or two won't have a dns entry - I assume this is a timing
issue but I haven't looked into it at the moment.
On 31 Jan 2015 23:55, "Aled Sage" <[email protected]> wrote:
Hi Duncan,
That's annoying, and surprising! Is there no hostname set at all, or a
non-unique hostname?
Do you know if the previous max length of 30 is the cut-off for hostname
being set on the VM? Maybe we could choose a number significantly bigger
than 30 but still not too big?
For Ambari, does it need a hostname that can be resolved from other VMs or
just a non-empty hostname?
(in some clouds for some apps, we ended up running a DNS server so that
hostnames would all resolve).
Aled
On 30/01/2015 16:51, Duncan Grant wrote:
Without a maximum name length (see
https://github.com/apache/incubator-brooklyn/pull/481) softlayer VMs are
created without a hostname.
Under these circumstances Ambari refuses to install.
Should I implement something specific to the ambari entities so that they
can work round this or do we need to find a more general fix?
I'd really like to keep the long names as then I can tell this difference
between my vms and those provisioned by Duncan.
Regards
Duncan
