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:rnori...@redhat.com]
*Sent:* Tuesday, October 10, 2017 6:14 AM
*To:* OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
*Cc:* Gary Kotton <gkot...@vmware.com>; Ihar Hrachyshka
<ihrac...@redhat.com>; arma...@gmail.com; miguel.lava...@huawei.com;
Luis Tomas Bolivar <ltoma...@redhat.com>; maruti.ka...@radisys.com;
Lajos Katona <lajos.kat...@ericsson.com>; Dayavanti Gopal Kamath
<dayavanti.gopal.kam...@ericsson.com>; George Offord
<george.off...@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.kat...@ericsson.com <mailto:lajos.kat...@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
<rnori...@redhat.com <mailto:rnori...@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.kat...@ericsson.com
<mailto:lajos.kat...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
<mailto:openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
