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

[Ali Gin]

Sweet. Verified and it works. Thanks Ben.



On Thu, Feb 1, 2018 at 4:41 PM, Ben Pfaff  wrote:

> On Tue, Jan 30, 2018 at 03:12:10PM -0800, Ali Gin wrote:
> > Sorry for the typo. I thought devs would catch that. So to summarize, I
> was
> > concerned about two issues:
> >
> > 1. killing the compute/HV gracefully should have deleted the chassis from
> > southbound db along with the bindings which did not happen
>
> "kill" doesn't trigger ovn-controller to shut down gracefully.  If you
> want it to remove its own chassis, you can use "ovs-appctl -t
> ovn-controller exit".
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Ben Pfaff]

On Tue, Jan 30, 2018 at 03:12:10PM -0800, Ali Gin wrote:
> Sorry for the typo. I thought devs would catch that. So to summarize, I was
> concerned about two issues:
> 
> 1. killing the compute/HV gracefully should have deleted the chassis from
> southbound db along with the bindings which did not happen

"kill" doesn't trigger ovn-controller to shut down gracefully.  If you
want it to remove its own chassis, you can use "ovs-appctl -t
ovn-controller exit".
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Ali Gin]

Thanks Han:

Sorry for the typo. I thought devs would catch that. So to summarize, I was
concerned about two issues:

1. killing the compute/HV gracefully should have deleted the chassis from
southbound db along with the bindings which did not happen
2. It is ok to leave the ports acting as orphan in northbound db if chassis
are deleted from southbound since we take it as expected.

So 2 is clear as we consider that as expected. However, for 1 do we need to
get a fix/code changes or am I missing something here because as per source
code it should have deleted?


Please advise for the inputs further.



On Tue, Jan 30, 2018 at 2:45 PM, Han Zhou  wrote:

> Hi Ali,
>
> Thanks for the details. Please see my comments inlined.
>
> On Mon, Jan 29, 2018 at 7:12 PM, Ali Gin  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.logovsdb-server.log
>  ovs-vswitchd.pid
> > br-int.snoop  ovn-controller.pidovsdb-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 1  0.0  0.0  14224   972 pts/0S+   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/0S+   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

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

[Han Zhou]

Hi Ali,

Thanks for the details. Please see my comments inlined.

On Mon, Jan 29, 2018 at 7:12 PM, Ali Gin  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.logovsdb-server.log
 ovs-vswitchd.pid
> br-int.snoop  ovn-controller.pidovsdb-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 1  0.0  0.0  14224   972 pts/0S+   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/0S+   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

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

[Ali Gin]

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.


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.logovsdb-server.log
ovs-vswitchd.pid
br-int.snoop  ovn-controller.pidovsdb-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 1  0.0  0.0  14224   972 pts/0S+   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/0S+   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.


Please for your inputs further.



Regards,
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev