[openstack-dev] l2gw

Lajos Katona lajos.katona at ericsson.com
Thu Oct 12 11:59:44 UTC 2017


Hi,

I copy here the answer from Maruti Haridas Kamat (part of the team which 
originally designed networking-l2gw) to the question why this was 
originally designed this way (no update is possible if there is an 
active connection on the gw):
"

I understand your use case, and we thought about it when we were 
designing the solution.

      Consider you have an interface and a physical switch that is 
present inside a neutron logical l2gw, and create a connection, then you 
have already created VXLAN-to-VLAN bindings on that interface on the 
physical switch or OVS. If you allow a user to update the gateway to 
modify the interface or switch list, then we need to fiddle with the 
VXLAN-to-VLAN bindings on the switch (es).

Steps:

 1. The user creates a logical gateway gw1 comprising of switch s1 and
    interface i1. No validation is performed here.
 2. The user creates a connection VXLAN (1000) to physical VLAN (100)
    binding. This performs all the validation inside the DB where the
    specified switch s1 and interface i1 exist. Whether the specified
    binding already exists or not. Finally, the plugin communicates to
    the southbound (agent) that creates the binding 1000 <-> 100 on the
    interface i1 on the switch (OVS).
 3. Consider that the user tries to add another interface i2 now to the
    same gateway gw1 using update gw1 command. It does not perform any
    validation. The entire validation we do in step 2 has to be moved to
    this step now. Also, the code (south bound) that makes changes on
    the OVS has to be introduced.
 4. We avoided this because the user may try to add and remove the
    interfaces in one go in the same command. If we had to allow update
    connection command, then internally we have to perform binding of
    vxlan with vlan for interface i2 but we have to remove the binding
    from i1 (considering i1 has been removed from the gw1) at the same time.
 5. It is not that it is not possible, but for the first version of L2gw
    in first six months, we thought of supporting basic framework of all
    these CLIs/REST APIs and enhance them later.

"
It will not give too much extra, but perhaps good to see the reasoning 
from another perspective.

Regards Lajos

On 2017-10-12 01:55, Dayavanti Gopal Kamath wrote:
>
> Hi ricardo,
>
> Since the l2gw connection semantics is applied on the l2gw object as a 
> whole, we could assume any connections applied on the l2gw object can 
> be retroactively applied to the ports that are affected by the the 
> l2gw update. so, if a port is added to an existing l2gw, all existing 
> l2gw connections get applied on that port, and if a port is deleted 
> from an l2gw, all existing l2gw connections get removed from this port.
>
> Thanks,
>
> daya
>
> *From:*Ricardo Noriega De Soto [mailto:rnoriega at redhat.com]
> *Sent:* Tuesday, October 10, 2017 6:14 AM
> *To:* OpenStack Development Mailing List (not for usage questions) 
> <openstack-dev at lists.openstack.org>
> *Cc:* Gary Kotton <gkotton at vmware.com>; Ihar Hrachyshka 
> <ihrachys at redhat.com>; armamig at gmail.com; miguel.lavalle at huawei.com; 
> Luis Tomas Bolivar <ltomasbo at redhat.com>; maruti.kamat at radisys.com; 
> Lajos Katona <lajos.katona at ericsson.com>; Dayavanti Gopal Kamath 
> <dayavanti.gopal.kamath at ericsson.com>; George Offord 
> <george.offord at ericsson.com>
> *Subject:* Re: [openstack-dev] l2gw
>
> I've been taking a look at the implementation and thinking about which 
> cases update should be allowed.
>
> At a first glance, I would say that we should allow updates:
>
> ·Add a new interface (neutron l2-gateway-update gw1 --device 
> name=hwvtep,interface_names=eth0,*eth1*) being eth1 the new interface.
>
> ·Delete interface (neutron l2-gateway-update gw1 --device 
> name=hwvtep,interface_names=eth0) removing eth1. In this case, we 
> should check that the port has not any active connection.
>
> However, in both cases there is a big issue, which is the granularity 
> of the segmentation-ids per port, right?? You cannot add or remove an 
> l2gw connection per port, which bring us to a dead end.
>
> Let's say I add eth1 to an existing l2gw. How can I get a vlan tag to 
> that interface?? There is not l2gw-connection-update command... and 
> trying to create the same one will fail. Even if you try to update the 
> l2gw instance specifying the seg-id per port, it won't be active until 
> a new connection is created.
>
> Folks, based on your experience, what's your take on this??
>
> IMHO, there is no easy way of solving this but with a big re-architecture.
>
> On Fri, Sep 29, 2017 at 1:46 PM, Lajos Katona 
> <lajos.katona at ericsson.com <mailto:lajos.katona at ericsson.com>> wrote:
>
>     Hi Ricardo,
>
>     That is the exception which gives us the trouble.
>
>     If you have ideas as you mentioned in which case a gw should be
>     updated, and in what not, that would be really nice.
>     Actually now we have a kind of development environment with
>     devstack and vtep emulator
>     (http://docs.openvswitch.org/en/latest/howto/vtep/) on the same
>     host, what do you think is that enough to go on with this problem?
>     I am not so sure if with vtep emulator we can cover all the good
>     and bad (I mean when we mustn't do the update for example) scenarios.
>
>     Regards
>     Lajos
>
>     On 2017-09-28 14:12, Ricardo Noriega De Soto wrote:
>
>         I see the exception now Lajos:
>
>         class L2GatewayInUse(exceptions.InUse):
>
>             message = _("L2 Gateway '%(gateway_id)s' still has active
>         mappings "
>
>                         "with one or more neutron networks.")
>
>         :-)
>
>         On Wed, Sep 27, 2017 at 6:40 PM, Ricardo Noriega De Soto
>         <rnoriega at redhat.com <mailto:rnoriega at redhat.com>> wrote:
>
>             Hey Lajos,
>
>             Is this the exception you are encountering?
>
>             (neutron) l2-gateway-update --device
>             name=hwvtep,interface_names=eth0,eth1 gw1
>
>             L2 Gateway 'b8ef7f98-e901-4ef5-b159-df53364ca996' still
>             has active mappings with one or more neutron networks.
>
>             Neutron server returns request_ids:
>             ['req-f231dc53-cb7d-4221-ab74-fa8715f85869']
>
>             I don't see the L2GatewayInUse exception you're talking
>             about, but I guess it's the same situation.
>
>             We should discuss in which case the l2gw instance could be
>             updated, and in which cases it shouldn't.
>
>             Please, let me know!
>
>             On Wed, Aug 16, 2017 at 11:14 AM, Lajos Katona
>             <lajos.katona at ericsson.com
>             <mailto:lajos.katona at ericsson.com>> wrote:
>
>                 Hi,
>
>                 We faced an issue with l2-gw-update, which means that
>                 actually if there are connections for a gw the update
>                 will throw an exception (L2GatewayInUse), and the
>                 update is only possible after deleting first the
>                 connections, do the update and add the connections back.
>
>                 It is not exactly clear why this restriction is there
>                 in the code (at least I can't find it in docs or
>                 comments in the code, or review).
>                 As I see the check for network connections was
>                 introduced in this patch:
>                 https://review.openstack.org/#/c/144097
>                 (https://review.openstack.org/#/c/144097/21..22/networking_l2gw/db/l2gateway/l2gateway_db.py)
>
>                 Could you please give me a little background why the
>                 update operation is not allowed on an l2gw with
>                 network connections?
>
>                 Thanks in advance for the help.
>
>                 Regards
>                 Lajos
>
>                 __________________________________________________________________________
>                 OpenStack Development Mailing List (not for usage
>                 questions)
>                 Unsubscribe:
>                 OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>                 <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>             -- 
>
>             Ricardo Noriega
>
>             Senior Software Engineer - NFV Partner Engineer | Office
>             of Technology  | Red Hat
>
>             irc: rnoriega @freenode
>
>
>
>         -- 
>
>         Ricardo Noriega
>
>         Senior Software Engineer - NFV Partner Engineer | Office of
>         Technology  | Red Hat
>
>         irc: rnoriega @freenode
>
>         __________________________________________________________________________
>
>         OpenStack Development Mailing List (not for usage questions)
>
>         Unsubscribe:OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>         <mailto:OpenStack-dev-request at lists.openstack.org?subject:unsubscribe>
>
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> -- 
>
> Ricardo Noriega
>
> Senior Software Engineer - NFV Partner Engineer | Office of Technology 
>  | Red Hat
>
> irc: rnoriega @freenode
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171012/a7307ecc/attachment-0001.html>


More information about the OpenStack-dev mailing list