Open Stack

On 01/30/2013 09:04 AM, Julien Danjou wrote:
> On Tue, Jan 29 2013, Sandy Walsh wrote:
> 
> Hi Sandy,
> 
>> https://blueprints.launchpad.net/ceilometer/+spec/new-ceilometer-agent
>>
>> Full spec: http://wiki.openstack.org/NewCeilometerAgent
>>
>> Video walkthrough of the StackTach worker (basis for proposal): http://www.youtube.com/watch?v=thaZcHuJXhM
>> (bump resolution and bandwidth, sorry for the um's)
> 
> What you propose is to drop the ceilometer-compute-agent, not the
> central one, you should make this clearer I think.
> Dropping the central one is just not going to happen anytime soon, but
> that doesn't sound like a problem to me for now -- and it doesn't seem
> it's a problem for you too.

Agreed. I think there is always going to be a need for some form of
agent. After talking with some of the Swift guys yesterday it was clear
that the only way to deal with the scale they are at is with looking at
the log files. I know Yahoo wants a similar approach.

There may be a terminology issue here too. I think of an Agent as
something deployed on the service node, while a Worker can be deployed
anywhere. I think for most cases, the Central "Agent" can be deployed
anywhere and make remote calls to the service in question.

As I mentioned to Angus in another thread, I have some ideas for how we
can piggy back these two requirements, but I think I need to focus on
getting everyone to see the problem first.

> IIUC your blueprint what you want to do is to retrieve data in a push
> model from notifications sent by Nova, rather than polling Nova+libvirt.
> 
> As I already pointed out to you on IRC, this has already been discussed
> back in November, the thread is at:
> 
>      http://lists.openstack.org/pipermail/openstack-dev/2012-November/002791.html
> 
> (I imagine you remember since it seems you participated)
> 
> As far as I know, what we have currently in the compute agent is an
> implementation of the result of this thread, and Eoghan did the
> necessary work on abstracting the virt driver etc on our side rather
> than in Nova side.

Yes, it was discussed, but I still don't think the arguments are valid
(for hypervisor/nova related things anyway). There's nothing the compute
agent currently does that can't be handled in notifications. And I know
the ops guys don't want to have to deploy more stuff on the compute nodes.

That's the whole purpose of this discussion, to reiterate that the
existing method is overkill.


> Now, if your blueprint is about implementing the necessary components
> into Nova to emit notifications with interesting information that
> Ceilometer wants (e.g. instance CPU or I/O usage) and use them from
> Ceilometer to drop the ceilometer-agent-compute, I don't think anybody
> -- from the Ceilometer side -- will be against this since, IIRC,
> Ceilometer crew were all for moving all the stuff into Nova back then.

It's twofold:
1. fix the notification data in Nova so that libvirt matches xen (or
vice-versa)
2. ditch the compute agent in favor of a pure notification-based worker.

> What you may want to do to start is likely to create a blueprint in Nova
> and get it validated. Changing stuff in Ceilometer then isn't likely to
> be a problem; as you know, we already consume a lot of notifications.

Agreed, can't imagine it being a problem as there's already a precedent
with Xen.

My personal concern is pounding more big BP's, plans, code around the
existing mechanism when we should be focused on an easier approach. But,
everyone has to share the vision. Sometimes when all you have is a
hammer, everything looks like a thumb. :)

Thanks!
-S