Hi Prakash, I think the issue is that the existing scenario’s use device drivers rather that protons.
While we can leverage existing integrations as baseline I do believe we will require a different composition. I actually wonder if FDS might be a good option as a starting point where it provides an integration point to the network control plane that does not derive from an adaptation of the ML2 architecture. / Chris On 2016-11-05, 00:16, "Prakash Ramchandran" <[email protected] on behalf of [email protected]> wrote: George, Your points are relevant. My only question is can we not reuse any of the existing Apex scenarios for the Danube listed under APEX in the following? https://wiki.opnfv.org/display/SWREL/Danube+Scenario+Status If there is any one that fits closest can we not adapt them like? os-odl_l2-sfc-ha Apex @Brady Johnson os-odl_l3-ovs-noha Apex @Thomas F Herbert check with Brady Johnson if they really have an HA for SFC and Thomas what it means to be noha? Since Gluon uses odl we can use ether one, with ha and noha as well l2/l3 options. Once we know what is difference between the two options and what changes we need to make to work with both l2 and l3 we can plan for if required for new scenario os-odl-gluon-noha Meanwhile we work with the two scenarios identified for seeing what it takes to adapt them, you go ahead and add the scenario os-odl-gluon-noha Apex@Georg Kunz to wiki page https://wiki.opnfv.org/display/SWREL/Danube+Scenario+Status Hope this helps David McBride and CI/CD and Infrastructure team to see how they can help us. Have a good weekend as we may be in for shock nextweek of AmeXit (following BreXit)!!! Thanks Prakash Prakash Ramchandran R&D USA FutureWei Technologies, Inc Email: [email protected] Work: +1 (408) 330-5489 Mobile: +1 (408) 406-5810 2330 Central Expy, Santa Clara, CA 95050, USA -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Georg Kunz Sent: Friday, November 04, 2016 7:24 AM To: HU, BIN ([email protected]); Nikolas Hermanns; Tim Irnich; [email protected]; [email protected]; [email protected]; [email protected]; Jeff Collins II Cc: [email protected] Subject: [opnfv-tech-discuss] [netready] Gluon integration in OPNFV Hi guys, As I mentioned during the last meeting, I am working towards installer support for Gluon in OPNFV. I believe it is highly beneficial for Gluon if we can make use of the CI and testing framework that OPNFV provides - in addition to the community building, of course. In this context, I have been in contact with Feng Pan from the Apex team. The first step towards an OPNFV integration is to define a new deployment scenario for Gluon. This involves a couple of aspects I'd like to get your input on: * SDN controller: There are currently two major SDN controllers in OPNFV: ODL and ONOS. Based on our experience and competence, I propose to start with ODL. * Network Service: This one is simple as we only have the L3VPN service at the moment. * Layer: The current scenarios distinguish between l2 and l3. For Gluon, I'd like to refrain from prematurely restricting the deployed network service. Hence, I propose to leave out any reference to l2 or l3. * Installer: As I mentioned, the Apex team voiced interest in supporting this activity. * High-availability: We have not looked into high-availability aspects of Gluon yet. Hence, I propose to define a noha scenario first. In summary, given the OPNFV scenario naming conventions, a first Gluon scenario would be called os-odl-gluon-noha. Let know what you think. Best regards Georg _______________________________________________ opnfv-tech-discuss mailing list [email protected] https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss _______________________________________________ opnfv-tech-discuss mailing list [email protected] https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss _______________________________________________ opnfv-tech-discuss mailing list [email protected] https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
