hi,
there has been a lot of work done across the community and Ceilometer
relating to versionedobjects. in Ceilometer particularly, this effort
has somewhat stalled as contributors are unsure of the benefits of
versionedobjects and how it relates to Ceilometer. there was a little
skeptism because it was originally sold as magic, but reading the slides
from Vancouver[1], it is not magic. rather it seems the main purpose is
to handle the evolution of schemas specifically over RPC which seems
neat but conceptually doesn't seem to fit into how Ceilometer functions.
looking at the patches, Chris brought up a good question in a review[2]
which to summarise:
If the ceilometer/aodh tools have direct connections to their data
storage level (they do) and do not use storable distributed objects
(on which rpc calls are made) in what sense are versioned objects
useful to the service?
My understanding is that in Nova (for example) versioned objects are
useful because rpc calls are made on storable objects that can be in
flight at any time across the distributed service and thus for their
to be smooth rolling upgrades those in flight objects need to be able
to be of different versions.
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:
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.
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
