Open Stack

On Thu, Nov 15, 2012 at 6:31 AM, Eoghan Glynn <eglynn at redhat.com> wrote:

>
> > And actually, option #4 you describe is option #3 with
> > multi-publisher on.
>
> Well, yes, if by 'on' you mean 'available in-process'.
>
> > That means option #3 where the only requirement for the
> > ceilometer-compute-agent (that would be moved into nova) is not
> > oslo.rpc only, but various publisher provided by Ceilometer.
>
> Exactly.
>
> > So my final option would be #4 possibly described as:
> > Rename ceilometer-compute-agent to nova-compute-metering and move it
> > into nova with its pollster. Make it uses the multi-publisher code
> > from Ceilometer so it's able to publish to a variety of destination
> > (ceilometer-collector, CW…) according to configuration, and polling
> > on interval that is configured via the publisher (as already
> > discussed on the multi-publisher blueprints).
> >
> >   + no request/reply (like option #1 and #2)
> >   + maintained by nova, so doesn't break
> >   + no need to have hypervizor specific code, possible to abstract
> >   + no lag
> >     option #1 do:
> >      -> request to nova-api via REST
> >         -> request to nova-compute via RPC
> >         <- reply to nova-api via RPC
> >      -> reply to ceilometer-agent-compute via REST
> >     option #2 do:
> >      -> request to nova-compute via RPC
> >      <- reply to nova-api via RPC
> >     option #3 do:
> >      -> notification emitted by nova-compute via RPC
> >       (on a time basis complicated to know and configure)
> >     option #4 do:
> >      -> something emitted by nova-compute via any media supported by
> >         ceilo publishers
> >       (on a time basis known by publishers configurations)
> >
> > But is Nova ready to import (optionnaly) some ceilometer code?
>
> So there appears to be some support from the ceilo side emerging
> for option #4, and you've hit the nail on the head there with that
> final question ...
>
> Would the nova project be happy to accept:
>
>  (a) the ceilo compute agent repackaged as nova-compute-metering
>
> and,
>
>  (b) the deployment of an additional daemon per compute node
>
> It would be great if we could get some response to the above from
> the nova "leadership" (loosely defined).
>
> Just to muddy the waters further if I may, let me throw a further
> option into the mix:
>
> 5. nova packages a consumable library layered over the hypervisor
>    driver, that just exposes the diagnostics available from libvirt
>    et al. The ceilo compute agent continues to exist under the ceilo
>    umbrella, but talks to the hypervisor directly via this stable,
>    versioned nova library.
>
>    + no remote calls required from ceilo-->nova-{api|compute}
>    - needs an independent versioning scheme
>    - still stuck in the "implicit trust" model?
>

I like this option best. It keeps any time-sensitive work for publishing
the messages out of the nova compute agent, where publishing monitoring
data may interfere with user-initiated actions like spinning up new
instances. It also doesn't leak abstractions in either direction (assuming
we get the API right) so the compute agent does not have to know about how
the monitoring data is being published and the monitoring agent gets a
clean API for asking about stats.

Doug


>
> Thoughts?
>
> Cheers,
> Eoghan
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121115/aca3614e/attachment.html>