[MidoNet-dev] Ephemeral node state before / after Version Sync (formerly known as Flush)

Ernest Artiaga ernest at midokura.com
Wed Mar 11 09:01:46 UTC 2015

Hi Tomohiko,

Thanks for preparing this and clarifying the flush behavior. I haven't gone
through the document in detail, but what you describe in the mail makes
sense to me: maintaining class subscriptions, and terminating per-object
subscriptions. My first suggestion would be that, when per-object
subscriptions are terminated, we should make the client clear that the
reason was a version bump, so it can act accordingly (e.g. resubscribing).
Maybe, from implementation point of view, it would be good to define a
specific 'NewTopologyVersionException' and emit it via the observable's

By the way, can we assume that the Ids of the topology objects will be
maintained after a version bump? (Mmm... maybe that answer is already in
the document... I'll have to read it :-))



On Wed, Mar 11, 2015 at 3:28 AM, Tomohiko Kimura <tomohiko at midokura.com>

> Hello all;
> I and Ryu have been working on the Importer spec
> <https://review.openstack.org/#/c/162382/> with the help from Irena. This
> document clarifies the use cases that the data sync (formerly known as
> flush) has to support and helps clarify its semantics.
> In this email I'd like to revisit how we should handle ephemeral node
> states (subscriptions / watchers to nodes such as bridges and nodes)
> before/after data sync. Previously we thought that the flush / version sync
> should be transparent to clients, e.g. the Agent subscribing to particular
> ports, etc. If the agent is subscribing to a port via an Observable exposed
> by new Storage, after data sync, the agent should keep receiving updates
> via the same Observable as if nothing has happened.
> According to the spec, the main use cases would be migration from other
> systems to MidoNet, MidoNet version upgrade, and recovery from data
> inconsistency between Neutron and MidoNet, possibly including rolling back
> to a previous data version. In those use cases I'm not sure if it makes
> sense to keep the old subscriptions to topology alive, but instead it's
> actually more desirable to close them once and let the Agents to
> re-subscribe to each instance cleanly.
> We can keep the class subscriptions (subscriptions to all Networks, to all
> Ports, etc.) But for instance subscriptions, in general we cannot tell if a
> subscription to a particular element type and an ID will be valid after
> sync. It may not even exist in case of data recovery / rollback, may point
> to a model that's different from the original model, or may result in
> obsolete / inconsistent state. In all of these use cases the administrator
> would be coordinating the sync, so I think it's just cleaner to clear all
> the old instance subscriptions and re-subscribe.
> Please let me know what you think.
> Best,
> Tomohiko
> _______________________________________________
> MidoNet-dev mailing list
> MidoNet-dev at lists.midonet.org
> http://lists.midonet.org/listinfo/midonet-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.midonet.org/pipermail/midonet-dev/attachments/20150311/995558d2/attachment.html>

More information about the MidoNet-dev mailing list