Hi Ali,

Thanks for the details. Please see my comments inlined.

On Mon, Jan 29, 2018 at 7:12 PM, Ali Gin <amgin...@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@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@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@fake-host:~/sandbox-192.168.83.8# kill 14063
>
> root@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@fake-host:~/sandbox-192.168.83.8# kill 13959
> root@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.
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to