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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
