in neutron gateway node, services neutron-metering-agent and neutron-lbaas-agent did not start

neutron-lbaas-agent logs

neutron-metering-agent logs

juju neutron-gateway unit logs

AccessRefused: (0, 0): (403) ACCESS_REFUSED - Login was refused using authentication mechanism AMQPLAIN. For details see the broker logfile.

Broken access credentials for RMQ.

I have the same issue and it differs which services every time.
Sometimes it is just one, the other time it's 4 or 5.

I have to restart those services my self and after a while juju reruns the status-update and it notices those are running.

Maybe the charm's can detect if rabbitmq-server is already running and active before even starting those services? Or trigger an update once rabbitmq-server is running?

Working on a fix in https://review.openstack.org/#/c/422318

Reviewed: https://review.openstack.org/422318
Committed: https://git.openstack.org/cgit/openstack/charm-rabbitmq-server/commit/?id=2472e1ca9fbd68cdd50640eadd071177ddc5968e
Submitter: Jenkins
Branch: master

commit 2472e1ca9fbd68cdd50640eadd071177ddc5968e
Author: David Ames <email address hidden>
Date: Fri Jan 13 20:36:12 2017 -0800

    Wait until clustered before running client hooks

    RabbitMQ takes some time to fully cluster. The charm was previously
    running amqp-relation-changed hooks whenever they were queued even
    if the cluster was not yet complete. This led to split brain
    scenarios. Client authentication to one or more nodes could fail.

    This change confirms the entire cluster is ready before running
    client amqp-relation-changed hooks.

    min-cluster-size can now be used to attempt to guarantee the cluster
    is ready with the expected number of nodes. If min-cluster-size is
    not set the charm will still determine based on the information
    available if all the cluster nodes are ready. Single node
    deployments are still possible.

    Partial-Bug: #1657245
    Closes-Bug: #1657176
    Change-Id: I870df71869c979e65a3a8764efdf35a746278507