yahoo-eng-team team mailing list archive

[OpenStack Infra <1804634@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.opendev.org/620349
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=ec875b42b6e92300093c895668532966de9e1327
Submitter: Zuul
Branch:    master

commit ec875b42b6e92300093c895668532966de9e1327
Author: Yang Youseok <ileixe@xxxxxxxxx>
Date:   Fri Nov 23 15:55:02 2018 +0900

    Add router_factory to l3-agent and L3 extension API
    
    Currently, most implementations override the L3NatAgent class itself
    for their own logic since there is no proper interface to extend
    RouterInfo class. This adds unnecessary complexity for developers
    who just want to extend router mechanism instead of whole RPC.
    
    Add a RouterFactory class that developer can registers RouterInfo class
    and delegate it for RouterInfo creation. Seperate functions and variables
    which currently used externally to abstract class from RouterInfo, so that
    extension can use the basic interface.
    
    Provide the router registration function to the l3 extension API so that
    extension can extend RouterInfo itself which correspond to each features
    (ha, distribtued, ha + distributed)
    
    Depends-On: https://review.openstack.org/#/c/620348/
    Closes-Bug: #1804634
    Partially-Implements: blueprint openflow-based-dvr
    Change-Id: I1eff726900a8e67596814ca9a5f392938f154d7b


** Changed in: neutron
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1804634

Title:
  [RFE] l3_agent should separate router_info creation logic

Status in neutron:
  Fix Released

Bug description:
  Currently, l3-agent has tightly coupled with router_info creation
  logic, so there is no way to make a big change of default router's
  behaviors. Even there are already many diverse routers (dvr, dvrha,
  dvr_snat...), every routers depend detailed implementation rather than
  structured interfaces. So it makes hard to add new feature.

  I found a majority of networking-* with l3 implementation just
  override core L3NatAgent and add a little tweaking functions to change
  default l3-agent behavior. IMHO, if there is clear interface in L3
  agent for specific router, they just add their router business logic
  rather than did not override core agent class. I noticed they did not
  change RPC mechanism a lot in agent side, and want to just make few
  tweak like us.

  What I suggest is make abstract class for router with minimal
  functions (initialize(), process()..), and add create router logic
  with dynamically configured router_info class. It decouples the
  creation and RPC controller so that plugin developer can easily change
  the default router behavior.

  To provide more specific use case, what we have done was to add linux
  VRF feature instead of namespace and East-West traffic is enabled by
  default so that there is no need to add GW / internal port at all. We
  do not need majority of functions except floating IP, but every kind
  of API / RPC is useful at the same time from server side.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1804634/+subscriptions