Open Stack

On 28/08/15 12:49 PM, Dan Smith wrote:
>> 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.

i like how your slides leveled it for us :)
>
>> 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.

we store everything as primitives: floats, time, integer, etc... since 
we need to query on attributes. it seems like versionedobjects might not 
be useful to our db configuration currently.

>
> 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.

i'm really looking forward to this. i think the entire Ceilometer team 
is waiting for someone to contractualise messages. right now it's a crap 
shoot when we listen to messages from other services.

cheers,

-- 
gord