[openstack-dev] [ceilometer] Follow up for nova_notifier discussion
Doug Hellmann
doug.hellmann at dreamhost.com
Mon Nov 19 18:09:14 UTC 2012
On Mon, Nov 19, 2012 at 12:06 AM, Jiang, Yunhong <yunhong.jiang at intel.com>wrote:
> > We would need to make the change everywhere instance-related events are
> > generated in nova so that the metadata for those events is always the
> same. I
>
> I think currently the notification_to_metadata() in both
> ceilometer/compute/notifications.py and ceilometer/plugin.py fetch only
> some field in the notification, depends on metadata_keys definition.
>
> IMHO it should be ok to use extra usage information only for
> "compute.instance.delete.start", which is a special case. And we can create
> a notification class in ceilometer specifically for
> "compute.instance.delete.start" event , fetching the metering information
> from extra usage info, put the corresponding metering information, either
> through the pollster, or publish it directly.
>
I think that might work. I'm not sure about introducing a special case to
the notification processing, but it's worth examining. I wonder if anyone
else would find the statistics useful in the other notifications?
>
> > think it would be better to change info_from_instance() in
> nova/notifications.py
> > so that the callers don't have to be updated, but I don't know if that
> module
>
> As that code in compute node also, so it should be ok to retrieve such
> information, but that means such information will be included in all
> instance event, including the usage audit, not sure if overkill.
>
It may be. I don't know how many values we would need that aren't being
included already. Have you done that analysis?
Doug
>
> --jyh
>
> > would have the information it needs to collect the appropriate stats
> from the
> > hypervisor. For events generated when the instance doesn't exist we would
> > want to substitute suitable constants (probably zero).
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121119/100f7c09/attachment.html>
More information about the OpenStack-dev
mailing list