Open Stack

> there was a little skeptism because it was originally sold as magic,
> but reading the slides from Vancouver[1], it is not magic.

I think I specifically said "they're not magic" in my slides. Not sure
who sold you them as magic, but you should leave them a
less-than-five-stars review.

> Ceilometer functions mainly on queue-based IPC. most of the
> communication is async transferring of json payloads where callback is
> not required. the basic workflows are:

This is specifically something versionedobjects should help with. The
remotable RPC method calls on an object are something that nova uses
heavily, but other projects don't use at all.

> polling agent --- topic queue ---> notification agent --- topic queue
> ---> collector (direct connection to db)

What happens if any of these components are running different versions
of the ceilometer code at one point? During an upgrade, you presumably
don't want to have to take all of these things down at once, and so the
"notification agent" might get an object from the "polling agent" that
is older or newer than it expects. More specifically, maybe the
collector is writing to older schema and gets a newer object from the
front of the queue with data it can't store. If you're getting
versionedobjects instead of raw json, you at least have an indication
that this is happening. If you get an older object, you might choose to
do something specific for the fields that are now in the DB schema, but
aren't in the object you received.

> OpenStack service --- topic queue ---> notification agent --- topic
> queue ---> collector (direct connection to db)

This is a good one. If Nova was sending notifications as objects, then
the notification agent would get a version with each notification,
knowing specifically when the notification is newer than it supports,
instead of us just changing things (on purpose or by accident) and you
breaking.

>From the storage in the DB perspective, I'm not sure what your
persistence looks like. However, we've been storing _some_ things in our
DB as serialized objects. That means that if we pull something out in a
year, after which time things in the actual object implementation have
changed, then we have an indication of what version it was stored in,
and presumably can apply a process to update it (or handle the
differences) at load time. I'm not sure if that's useful for ceilometer,
but it is definitely useful for nova, where we can avoid converting
everything in the database every time we add/change a field in something
-- a process that is very critical to avoid in our goals for improving
the upgrade experience for operators.

So, I dunno if ceilometer needs to adopt versionedobjects for anything.
It seems like it would apply to the cases you describe above, but if
not, there's no reason to use it just because others are. Nova will
(when I stop putting it off) start sending notifications as serialized
and versioned objects at some point, but you may choose to just unwrap
it and treat it as a json blob beyond the handler, if that's what is
determined as the best course.

--Dan