Re: [Rdo-list] rdo-manager hostname issues with rabbitmq
On Thu, Apr 30, 2015 at 12:22:04PM -0400, Lars Kellogg-Stedman wrote:
On Thu, Apr 30, 2015 at 08:15:35AM -0400, James Slagle wrote:
> For baremetal, I've added some notes to the docs to hopefully cover the
> requirements.
I'm not familiar with AMQP. Is there a particular reason why rabbitmq
is so sensitive to hostname issues? I was surprised to run into this
with a packstack install the other day, especially given that
packstack configures everything uses ip addresses rather than names.
rabbitmq seems to perform some sort of reverse-lookup of the hostname,
and there was a stale dns entry out there that it was picking up.
This wouldn't have caused a problem for anything else (because the
entire configuration is based on ip addresses rather than hostnames),
but it prevented rabbitmq from starting up correctly.
Is there any chance that we should also be pursuing this as a bug in
rabbitmq? Or is there a configuration we can tweak in rabbitmq that
will make it less sensitive to hostname issues?
Possibly.
For this particular case anyway, it took me a little while to reproduce the
issue. Eventually I realized that if I set a hostname, then logged out and
then back in prior to installing the undercloud, I could never reproduce an
issue. That led me to believe it was environment related, and further, caused
by $HOSTNAME.
grep'ing through the rabbitmq-server code, I saw that:
https://github.com/rabbitmq/rabbitmq-server/blob/master/scripts/rabbitmq-env
uses the $HOSTNAME value.
In my earlier email I said that rabbitmq-server sources rabbitmq-env (which is
true), but the actual problem I think is that rabbitmqctl also sources
rabbitmq-env, and puppetlabs-rabbitmq calls rabbitmqctl all over the place.
So, honestly, this could be a bug in rabbitmq-env, I'm not sure what the
accepted expectations are around $HOSTNAME, if there even are any. Note though
that rabbitmq-env also has it's *own* configuration file where a hostname could
be set as well.
--
-- James Slagle
--