Open Stack

On Thu, 27 Aug 2015 15:37:24 -0400
gord at live.ca (gord chung) wrote:

> polling agent --- topic queue ---> notification agent --- topic queue 
> ---> collector (direct connection to db)
> or
> OpenStack service --- topic queue ---> notification agent --- topic 
> queue ---> collector (direct connection to db)
> or
> from Aodh/alarming pov:
> ceilometer-api (direct connection to db) <--- http --- alarm evaluator 
> --- rpc ---> alarm notifier --- http ---> [Heat/other]
> 
> based on the above workflows, is there a good place for adoption of 
> versionedobjects? and if so, what is the benefit? most of us are keen on 
> adopting consistent design practices but none of us can honestly 
> determine why versionedobjects would be beneficial to Ceilometer. if 
> someone could explain it to us like we are 5 -- it's probably best to 
> explain everything/anything like i'm 5 -- that would help immensely on 
> moving this work forward.

Hi Gordon,

The first thing that come to my mind is the database schema changes -
this is the area that OVO is aiming at. Even though you don't have a
need for the schema changing today, it might happen in the future.

So imagine we have new versions of the schema for the events, alarms or
samples in ceilometer introduced in Mitaka release while you have all
your ceilo services on Liberty release. To upgrade ceilometer you'll
have to stop all services to avoid data corruption. With
versionedobjects you can do this one by one without disrupting
telemetry jobs.

The other thing, maybe not so obvious, is to put versionedobject layer
between application and the MongoDB driver, so that all of the schema
changes will be automatically handled on ovo, and also serialization
might also be done on such layer.

Hope that clear your doubts.

-- 
Cheers,
Roman Dobosz