Indeed the semantics of the data should be outside the scope of federation, though we do see room for application specific "federation plugins" to potentially handle cases where it makes sense to transform or otherwise alter data before/after federating it. As such, the API's you suggest are certainly relevant.
In our POC we just wanted to show that an existing application (NetVirt) could indeed be manipulated effectively by injecting MD-SAL objects from a remote cluster. No generic federation was implemented for this. Looking forward to a fruitful discussion in Seattle :) Gidi -----Original Message----- From: Robert Varga [mailto:n...@hq.sk] Sent: Thursday, 28 July 2016 21:46 To: Kaempfer, Gideon <g...@hpe.com>; jmed...@cisco.com Cc: Noy, Ariel <ariel....@hpe.com>; Sela, Guy <guy.s...@hpe.com>; controller-dev@lists.opendaylight.org; mdsal-...@lists.opendaylight.org; netvirt-...@lists.opendaylight.org Subject: Re: [mdsal-dev] Serialize/Deserialize DTOs to JSON On 07/28/2016 05:02 PM, Kaempfer, Gideon wrote: > Hi Robert, Hello, > For the Carbon cycle we are planning to implement a Federation Service for > ODL. The idea would be to have the ability to federate information coming > from MD-SAL to ODL instances outside of the local cluster. The first concrete > use case would be to federate NetVirt such that Neutron networks on different > sites (OpenStack clouds) could be seamlessly interconnected at L2 or L3 over > VXLAN tunnels just like compute hosts are connected within a single site. We > already have a POC implementation demonstrating this. > > Looking forward, we envision other services leveraging this federation > capability as well. It could be used as a means for geographical distribution > of ODL clusters as well as a means to scale ODL beyond what is currently > possible within a single ODL cluster (which has certain limitations related > to the way MD-SAL clustering works). > > We would be more than happy to exchange ideas on the above in preparation for > the Carbon DDF. Ah, neat idea. It definitely needs to be implemented on the Binding Independent layer, i.e. using DOM* interfaces and NormalizedNodes, as I think the service ends up not being tied to actual semantics of the data. Our current thinking around integrating disparate data management engines is outlined in https://wiki.opendaylight.org/view/MD-SAL:Boron:Conceptual_Data_Tree. The APIs involved are already implemented in Boron and integrated with the in-memory data store, the CDS integration is being worked on. How does it align with your POC? At any rate, I hope we can get a brainstorming session going in Seattle :) Bye, Robert _______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
