Open Stack

On 28/08/15 12:18 PM, Roman Dobosz wrote:
> 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.
are versions checked for every single message? has anyone considered the 
overhead to validating each message? since ceilometer is queue based, we 
could technically just publish to a new queue when schema changes... and 
the consuming services will listen to the queue it knows of.

ie. our notification service changes schema so it will now publish to a 
v2 queue, the existing collector service consumes the v1 queue until 
done at which point you can upgrade it and it will listen to v2 queue.

this way there is no need to validate/convert anything and you can still 
take services down one at a time. this support doesn't exist currently 
(i just randomly thought of it) but assuming there's no flaw in my idea 
(which there may be) isn't this more efficient?
>
> 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.

i don't quite understand this, is this a mongodb specific solution? 
admittedly the schemaless design of mongo i can imagine causing issues 
but currently we're trying to avoid wasting resources on existing 
mongodb solution as we attempt to move to new api. if it's just a 
generic db solution, i'd be interested to apply it to future designs.

cheers,

-- 
gord