[ovs-dev] deleting chassis doesn't delete the lport and lflows from northd

Han Zhou zhouhan at gmail.com
Tue Jan 30 22:45:29 UTC 2018


Hi Ali,

Thanks for the details. Please see my comments inlined.

On Mon, Jan 29, 2018 at 7:12 PM, Ali Gin <amginwal at gmail.com> wrote:
>
> Hi team/Ben:
>
> Want to get inputs about compute de-comm use case. So when deleting the
chassis from southd after gracefully killing the compute, doesn't delete
the ports binded to the northd lswitch.
>
I think you had a typo here: s/southd/south-bound DB, s/northd/north-bound
DB.

>
> Below is the detail of a sandbox from recent scale test env.
> root at fake-host:~/sandbox-192.168.83.8# ls
> br0.mgmt      db.sock                   ovn-uuid
 ovs-vswitchd.13976.ctl
> br0.snoop     ovn-controller.14063.ctl  ovsdb-server.13959.ctl
 ovs-vswitchd.log
> br-int.mgmt   ovn-controller.log        ovsdb-server.log
 ovs-vswitchd.pid
> br-int.snoop  ovn-controller.pid        ovsdb-server.pid
 ovs-vswitchd.sh
> conf.db       ovn-controller.sh         ovsdb-server.sh         sandbox.rc
> root at fake-host:~/sandbox-192.168.83.8# ps aux | grep 14063
> root     14063  1.9  0.0 114904 88456 ?        Ss   00:23  21:53
ovn-controller --detach --no-chdir --pidfile -vconsole:off -vsyslog:off
-vfile:info --log-file
> root     44441  0.0  0.0  14224   972 pts/0    S+   19:30   0:00 grep
--color=auto 14063
> root at fake-host:~/sandbox-192.168.83.8# kill 14063
>
> root at fake-host~/sandbox-192.168.83.8# ps aux | grep 13976
> root     13976  1.2  0.8 2480864 2325768 ?     Ssl  00:23  13:49
ovs-vswitchd --detach --no-chdir --pidfile -vconsole:off -vsyslog:off
-vfile:info --log-file --enable-dummy=override
> root     44688  0.0  0.0  14224  1008 pts/0    S+   19:30   0:00 grep
--color=auto 13976
>
> root at fake-host:~/sandbox-192.168.83.8# kill 13959
> root at fake-host:~/sandbox-192.168.83.8# ovs-vsctl show
> ovs-vsctl: unix:/root/sandbox-192.168.83.8/db.sock: database connection
failed (No such file or directory)
>
> southdb details:
> Chassis "7aa3f562-4b8c-4b63-b22a-d7da7fcdedcb"
>     hostname: "fake234"
>     Encap geneve
>         ip: "192.168.83.8/16"
>         options: {csum="true"}
>     Port_Binding "lport_5ead7e_UCUe2A"
>     Port_Binding "lport_5ead7e_LaD1jw"
>     Port_Binding "lport_5ead7e_XcVUdA"
>     Port_Binding "lport_5ead7e_wPkica"
>     Port_Binding "lport_5ead7e_Ms539W"
>     Port_Binding "lport_5ead7e_UGdRuk"
>     Port_Binding "lport_5ead7e_8jHLXB"
>     Port_Binding "lport_5ead7e_IKRwFf"
>     Port_Binding "lport_5ead7e_U2eXES"
>     Port_Binding "lport_5ead7e_UIVysQ"
>
> ovn-sbctl chassis-del 7aa3f562-4b8c-4b63-b22a-d7da7fcdedcb
>
> ovn-nbctl show 5cf94839-d4b6-424c-9081-20739e48eb53
>     port lport_5ead7e_UCUe2A
>         addresses: ["5e:7f:47:62:6b:d0 172.145.74.24"]
>
> ovn-sbctl lflow-list | grep 5e:7f:47:62:6b:d0
>   table=0 (ls_in_port_sec_l2  ), priority=50   , match=(inport ==
"lport_5ead7e_UCUe2A" && eth.src == {5e:7f:47:62:6b:d0}), action=(next;)
>   table=2 (ls_in_port_sec_nd  ), priority=90   , match=(inport ==
"lport_5ead7e_UCUe2A" && eth.src == 5e:7f:47:62:6b:d0 && arp.sha ==
5e:7f:47:62:6b:d0), action=(next;)
>   table=2 (ls_in_port_sec_nd  ), priority=90   , match=(inport ==
"lport_5ead7e_UCUe2A" && eth.src == 5e:7f:47:62:6b:d0 && ip6 && nd &&
((nd.sll == 00:00:00:00:00:00 || nd.sll == 5e:7f:47:62:6b:d0) || ((nd.tll
== 00:00:00:00:00:00 || nd.tll == 5e:7f:47:62:6b:d0)))), action=(next;)
>   table=15(ls_in_l2_lkup      ), priority=50   , match=(eth.dst ==
5e:7f:47:62:6b:d0), action=(outport = "lport_5ead7e_UCUe2A"; output;)
>   table=8 (ls_out_port_sec_l2 ), priority=50   , match=(outport ==
"lport_5ead7e_UCUe2A" && eth.dst == {5e:7f:47:62:6b:d0}), action=(output;)
>
> So is it kept on purpose or should we make code changes to take care of
deleting the same from northd too since the lports are left orphan.
>

After deleting chassis from SB, lports are expected to be kept in NB and
logical flows are expected to be kept in SB, since port-binding and logical
port operations are independent.

However, I would expect we don't have to manually delete the chassis from
SB if it is gracefully shutdown. Maybe it was not graceful for some reason.


More information about the dev mailing list