On Wed, Mar 14, 2018 at 2:31 PM, N Vivekanandan <n.vivekanan...@ericsson.com > wrote:
> ‘included infrautils-dev > just FYI: infrautils actually cannot host any code related to the MD-SAL Datastore, see https://wiki.opendaylight.org/view/Infrastructure_Utilities:Main#Introduction for background. Perhaps you also want to look at whether you would not possibly want to use some other existing MQ type thing instead of building this yourself? I guess one advantage you would have to build your own MQ on top of the DS is that you could have TXs spanning MQ processing and other reads/writes in the Op DS - if that's of interest to you. How well e.g. a huge list of such messages in the DS would scale is something you should perhaps POC, depending on your requirements. > *From:* N Vivekanandan > *Sent:* Tuesday, March 06, 2018 9:43 PM > *To:* 'controller-dev@lists.opendaylight.org' <controller-dev@lists. > opendaylight.org>; odl netvirt dev <netvirt-...@lists.opendaylight.org>; > genius-...@lists.opendaylight.org > *Subject:* EventQueue overlay on top of MDSAL (on Operational Shard) > > > > Hi OpenDaylight’ers, > > > > We are from the NETVIRT project of OpenDaylight Controller and we are > involved in > > driving the “L3VPN-as-a-Service” subproject within the same. > > > > This service is triggered/realized by using Neutron Routers and/or > Neutron BGPVPN feature orchestrations. > > > > We had an opportunity to learn few failures on production deployments of > ODL (3-node), where we > > figured out that such problems were due to improper serialization of > workflows inside L3VPN-service > > scaled across the 3-nodes of the ODL cluster. > > > > In order to serialize such workflows (few eg): > > > > VM Migration, > > VM Evacuation, > > VIP movement in the cloud between VM ports etc ), > > > > we were contemplating to generate and store Event Objects into a Queue > with the backend for > > the queue being MD-SAL Datastore (Operational Shard). > > > > While we understand that OP Datastores are used for only State-information > management inside ODL, we wanted an > > Event-Serialization mechanism that will spawn across the ODL cluster and > consumers servicing such events in that order > > provides for consistent runtime-behaviour across the nodes of the ODL > cluster. > > > > Can you please let us know if this approach of wrapping the Op Datastores > with a Queuing framework, and > > using the same for Event-Serialization is wise to pursue? > > > > Are there other implementations within ODL that use Event Queues (that are > usable across a 3-node cluster) , and > > if so can you please point us to them ? > > > > -- > > Thanks, > > > > Vivek > > > > _______________________________________________ > genius-dev mailing list > genius-...@lists.opendaylight.org > https://lists.opendaylight.org/mailman/listinfo/genius-dev > >
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
