1. Topics
  2. L2gw with ODL

L2gw with ODL

daya k
 

i agree maruti, not be feasible to combine the 2 functions under the ML2 mechanism driver, as the driver will follow its own growth path, driven by the openstack community. unifying at the provider level (via the neutron northbound) is sufficient for us to implement functionality across core as well as non-core resources.

thanks,
daya


From: "Kamat, Maruti Haridas" <maruti.kamat@...>
To: Dayavanti Gopal Kamath <dayavanti.gopal.kamath@...>; Hema Gopalkrishnan <hema.gopalkrishnan@...>; Vishal Thapar <vishal.thapar@...>; "Kenchappa, Ravindra" <ravindra.kenchappa@...>; "Suryanarayanan, Aswin" <aswin.suryanarayanan@...>; 'Anil Vishnoi' <vishnoianil@...>; 'Flavio Fernandes' <ffernand@...>; 'Sam Hague' <shague@...>; 'Chris Wright' <chrisw@...>; 'Kyle Mestery' <mestery@...>; Prem sankar G <prem.sankar.g@...>; Abhijit Kumbhare <abhijit.kumbhare@...>; Ravi Sundareswaran <ravi.sundareswaran@...>; "Vasudevan, Swaminathan (PNB Roseville)" <swaminathan.vasudevan@...>; "'afredette@...'" <afredette@...>; "Ravi_Sabapathy@..." <Ravi_Sabapathy@...>; "Yapeng.Wu@..." <Yapeng.Wu@...>; "sumit@..." <sumit@...>; "ovsdb-dev@..." <ovsdb-dev@...>
Sent: Wednesday, July 22, 2015 12:17 PM
Subject: [ovsdb-dev] L2gw with ODL

Hi Everyone,
 
  I would like to shed some light on why l2gw logic in OpenStack neutron cannot be a part of the ODL ML2 mechanism driver.
 
  1. The core plugin (today also called ML2 plugin) is designed to handle NB REST APIs only for the core resources (network, subnet and ports). Whenever a CUD operation is performed on these core resources, the core ML2 plugin  invokes the configured mechanism drivers (including the ODL mech driver).
  2. As the L2gw resources (logical l2-gateway and l2-gateway-connections) are not core resources, we introduced a new service plugin in Neutron in Kilo release. Neutron allows core plugin and service plugin to co-exist.
  3. The L2gw service plugin implements NB REST APIs for the logical l2-gateway and l2-gateway-connection resources. These calls do not land in the core plugin (the ODL ML2 plugin).
  4. Today, the L2gw service plugin is implemented (tight coupling) in such a way that it assumes that it has to communicate with an L2gw agent over the RabbitMQ message bus. I am trying to modularize this code to put it in a service plugin’s provider driver (like how LBaaS, or VPNaaS does). The reason: the user can configure the ODL provider driver for the l2gw service plugin so that this driver will proxy the NB calls into ODL REST calls (without needing RabbitMQ bus and the l2gw agent).
  5. The existing ODL mechanism driver for the ODL ML2 plugin will only handle port CUD operations to be sent to the ODL controller.
    6.
 
Please let me know if you have any questions, or need any further clarifications.
 
Thanks,
Maruti
 

_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
Kamat, Maruti Haridas <maruti.kamat@...>
 

Hi Everyone,
 
  I would like to shed some light on why l2gw logic in OpenStack neutron cannot be a part of the ODL ML2 mechanism driver.
 
  1. The core plugin (today also called ML2 plugin) is designed to handle NB REST APIs only for the core resources (network, subnet and ports). Whenever a CUD operation is performed on these core resources, the core ML2 plugin  invokes the configured mechanism drivers (including the ODL mech driver).
  2. As the L2gw resources (logical l2-gateway and l2-gateway-connections) are not core resources, we introduced a new service plugin in Neutron in Kilo release. Neutron allows core plugin and service plugin to co-exist.
  3. The L2gw service plugin implements NB REST APIs for the logical l2-gateway and l2-gateway-connection resources. These calls do not land in the core plugin (the ODL ML2 plugin).
  4. Today, the L2gw service plugin is implemented (tight coupling) in such a way that it assumes that it has to communicate with an L2gw agent over the RabbitMQ message bus. I am trying to modularize this code to put it in a service plugin’s provider driver (like how LBaaS, or VPNaaS does). The reason: the user can configure the ODL provider driver for the l2gw service plugin so that this driver will proxy the NB calls into ODL REST calls (without needing RabbitMQ bus and the l2gw agent).
  5. The existing ODL mechanism driver for the ODL ML2 plugin will only handle port CUD operations to be sent to the ODL controller.
    6.
 
Please let me know if you have any questions, or need any further clarifications.
 
Thanks,
Maruti
 

1 - 2 of 2