[openstack-dev] [ceilometer] [openstack-ansible] OpenStack-Ansible Ceilometer Configuration

Alex Cantu miguel.cantu at RACKSPACE.COM
Wed Feb 24 00:35:39 UTC 2016


Nate,


That's right. Initially there wasn't any work done to the Ansible playbooks to turn off Aodh alarming when deploying Ceilometer.

Ideally the playbooks would check to see if any alarm hosts are defined. If so, then turn on the Aodh configurations within Ceilometer. If not, then leave those configurations out.


It's worth noting that Ceilometer Alarms are deprecated in Liberty in favor of Aodh. If you turn off Aodh, then that feature will not be available to you.

Feel free to file a bug explaining the situation, and if you are feeling up for it -- add the logic in to check for Aodh hosts :).


-Alex

________________________________
From: Potter, Nathaniel <nathaniel.potter at intel.com>
Sent: Tuesday, February 23, 2016 5:56 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [ceilometer] [openstack-ansible] OpenStack-Ansible Ceilometer Configuration

Hi Alex,

So it's looking to me like my problem was being caused by openstack-ansible trying to set up aodh although I didn't configure it and didn't want to use it. In ceilometer.conf I found that in the [database] section the metering and event connections were correctly looking for mongodb at the IP I set as my bind IP, but it was also adding an alarm connection looking for an aodh user in the database at localhost. This was causing the ceilometer API to time out repeatedly looking for the connection that didn't exist. I don't have any aodh configuration set up in /etc/openstack_deploy, so should that line not have been put into my ceilometer.conf?

Thanks,
Nate
From: Alex Cantu [mailto:miguel.cantu at RACKSPACE.COM]
Sent: Wednesday, February 17, 2016 4:48 PM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [ceilometer] [openstack-ansible] OpenStack-Ansible Ceilometer Configuration


Nate,



The mongodb host can be anywhere, so long as it can reached by the ceilometer containers (on the same network).

What branch are you working from? Master and Liberty should have no problems as far as I'm aware. There is a bug open in regards to authentication with swift, but everything else should work fine.



Feel free to send over your ceilometer-api, ceilometer-notification-agent, and ceilometer-pollster logs on a pastebin that way I can take a look.



-Alex

________________________________
From: Potter, Nathaniel <nathaniel.potter at intel.com<mailto:nathaniel.potter at intel.com>>
Sent: Wednesday, February 17, 2016 4:17 PM
To: openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [ceilometer] [openstack-ansible] OpenStack-Ansible Ceilometer Configuration

Hi everyone,

I've been working on setting up a 10 node OpenStack installation with ceilometer using openstack-ansible, but the way I've configured it isn't working for me. I've tried following these instructions http://docs.openstack.org/developer/openstack-ansible/install-guide/configure-ceilometer.html, doing these steps -


-        I set up MongoDB on the metering-infra_host, making the bind_ip the br-mgmt IP of that host and creating the ceilometer user.

-        In /etc/openstack_deploy/conf.d/ceilometer.yml I have a compute host under metering-compute_hosts and the infra host that I configured MongoDB on in my metering-infra_hosts.

-        I also set the ceilometer_db_ip in user_variables to be equal to the bind_ip set on the infra host.

Running the ceilometer installation playbook is successful, but when I log into the utility container and try to run ceilometer meter-list it times out and says 'Service Unavailable (HTTP 503)'.

Does anyone see anywhere that I went wrong in these steps, should bind-ip be set to something else, or should I be configuring this database on the compute host rather than the infra? The documentation wasn't entirely clear on that point.

Thanks,
Nate

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160224/dda60261/attachment.html>


More information about the OpenStack-dev mailing list