Re: [openstack-dev] [Neutron] initial OVN testing
On Mar 31, 2015, at 12:34 AM, Kevin Benton blak...@gmail.com wrote: Very cool. What's the latest status on data-plane support for the conntrack based things like firewall rules and conntrack integration? As Miguel mentioned, we have working code: https://github.com/justinpettit/ovs/tree/conntrack We're in the process of trying to get the support upstreamed in the Linux kernel. --Justin __ 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
Re: [openstack-dev] [Neutron] initial OVN testing
That’s super nice ;) !!! :D
I’m prototyping over here [1] to gather some benchmarks for the summit
presentation
about “Taking Security Groups To Ludicrous Speed with Open vSwitch” with Ivar,
Justin
and Thomas.
I know Justin and Joe have been doing good advances on it ;) [3] lately.
[1] https://review.openstack.org/#/c/167671/
[2] https://github.com/justinpettit/ovs/tree/conntrack
[3] https://github.com/justinpettit/ovs/commits/conntrack
Miguel Ángel Ajo
On Tuesday, 31 de March de 2015 at 9:34, Kevin Benton wrote:
Very cool. What's the latest status on data-plane support for the conntrack
based things like firewall rules and conntrack integration?
On Mon, Mar 30, 2015 at 7:19 PM, Russell Bryant rbry...@redhat.com
(mailto:rbry...@redhat.com) wrote:
On 03/26/2015 07:54 PM, Russell Bryant wrote:
Gary and Kyle, I saw in my IRC backlog that you guys were briefly
talking about testing the Neutron ovn ml2 driver. I suppose it's time
to add some more code to the devstack integration to install the current
ovn branch and set up ovsdb-server to serve up the right database for
this. I'll try to work on that tomorrow. Of course, note that all we
can set up right now is the northbound database. None of the code that
reacts to updates to that database is merged yet. We can still go ahead
and test our code and make sure the expected data makes it there, though.
With help from Kyle Mestery, Gary Kotton, and Gal Sagie, some great
progress has been made over the last few days. Devstack support has
merged and the ML2 driver seems to be doing the right thing.
After devstack runs, you can see that the default networks created by
devstack are in the OVN db:
$ neutron net-list
+--+-+--+
| id | name| subnets
|
+--+-+--+
| 1c4c9a38-afae-40aa-a890-17cd460b314b | private |
115f27d1-5330-489e-b81f-e7f7da123a31 10.0.0.0/24 (http://10.0.0.0/24) |
| 69fc7d7c-6906-43e7-b5e2-77c059cf4143 | public |
6b5c1597-4af8-4ad3-b28b-a4e83a07121b |
+--+-+--+
$ ovn-nbctl lswitch-list
47135494-6b36-4db9-8ced-3bdc9b711ca9
(neutron-1c4c9a38-afae-40aa-a890-17cd460b314b)
03494923-48cf-4af5-a391-ed48fe180c0b
(neutron-69fc7d7c-6906-43e7-b5e2-77c059cf4143)
$ ovn-nbctl lswitch-get-external-id
neutron-1c4c9a38-afae-40aa-a890-17cd460b314b
neutron:network_id=1c4c9a38-afae-40aa-a890-17cd460b314b
neutron:network_name=private
$ ovn-nbctl lswitch-get-external-id
neutron-69fc7d7c-6906-43e7-b5e2-77c059cf4143
neutron:network_id=69fc7d7c-6906-43e7-b5e2-77c059cf4143
neutron:network_name=public
You can also create ports and see those reflected in the OVN db:
$ neutron port-create 1c4c9a38-afae-40aa-a890-17cd460b314b
Created a new port:
+---+-+
| Field | Value
|
+---+-+
| admin_state_up| True
|
| allowed_address_pairs |
|
| binding:vnic_type | normal
|
| device_id |
|
| device_owner |
|
| fixed_ips | {subnet_id:
115f27d1-5330-489e-b81f-e7f7da123a31, ip_address: 10.0.0.3} |
| id| e7c080ad-213d-4839-aa02-1af217a6548c
|
| mac_address | fa:16:3e:07:9e:68
|
| name |
|
| network_id| 1c4c9a38-afae-40aa-a890-17cd460b314b
|
| security_groups | be68fd4e-48d8-46f2-8204-8a916ea6f348
|
| status| DOWN
|
| tenant_id | ed782253a54c4e0a8b46e275480896c9
|
Re: [openstack-dev] [Neutron] initial OVN testing
Very cool. What's the latest status on data-plane support for the conntrack
based things like firewall rules and conntrack integration?
On Mon, Mar 30, 2015 at 7:19 PM, Russell Bryant rbry...@redhat.com wrote:
On 03/26/2015 07:54 PM, Russell Bryant wrote:
Gary and Kyle, I saw in my IRC backlog that you guys were briefly
talking about testing the Neutron ovn ml2 driver. I suppose it's time
to add some more code to the devstack integration to install the current
ovn branch and set up ovsdb-server to serve up the right database for
this. I'll try to work on that tomorrow. Of course, note that all we
can set up right now is the northbound database. None of the code that
reacts to updates to that database is merged yet. We can still go ahead
and test our code and make sure the expected data makes it there, though.
With help from Kyle Mestery, Gary Kotton, and Gal Sagie, some great
progress has been made over the last few days. Devstack support has
merged and the ML2 driver seems to be doing the right thing.
After devstack runs, you can see that the default networks created by
devstack are in the OVN db:
$ neutron net-list
+--+-+--+
| id | name| subnets
|
+--+-+--+
| 1c4c9a38-afae-40aa-a890-17cd460b314b | private |
115f27d1-5330-489e-b81f-e7f7da123a31 10.0.0.0/24 |
| 69fc7d7c-6906-43e7-b5e2-77c059cf4143 | public |
6b5c1597-4af8-4ad3-b28b-a4e83a07121b |
+--+-+--+
$ ovn-nbctl lswitch-list
47135494-6b36-4db9-8ced-3bdc9b711ca9
(neutron-1c4c9a38-afae-40aa-a890-17cd460b314b)
03494923-48cf-4af5-a391-ed48fe180c0b
(neutron-69fc7d7c-6906-43e7-b5e2-77c059cf4143)
$ ovn-nbctl lswitch-get-external-id
neutron-1c4c9a38-afae-40aa-a890-17cd460b314b
neutron:network_id=1c4c9a38-afae-40aa-a890-17cd460b314b
neutron:network_name=private
$ ovn-nbctl lswitch-get-external-id
neutron-69fc7d7c-6906-43e7-b5e2-77c059cf4143
neutron:network_id=69fc7d7c-6906-43e7-b5e2-77c059cf4143
neutron:network_name=public
You can also create ports and see those reflected in the OVN db:
$ neutron port-create 1c4c9a38-afae-40aa-a890-17cd460b314b
Created a new port:
+---+-+
| Field | Value
|
+---+-+
| admin_state_up| True
|
| allowed_address_pairs |
|
| binding:vnic_type | normal
|
| device_id |
|
| device_owner |
|
| fixed_ips | {subnet_id:
115f27d1-5330-489e-b81f-e7f7da123a31, ip_address: 10.0.0.3} |
| id| e7c080ad-213d-4839-aa02-1af217a6548c
|
| mac_address | fa:16:3e:07:9e:68
|
| name |
|
| network_id| 1c4c9a38-afae-40aa-a890-17cd460b314b
|
| security_groups | be68fd4e-48d8-46f2-8204-8a916ea6f348
|
| status| DOWN
|
| tenant_id | ed782253a54c4e0a8b46e275480896c9
|
+---+-+
List ports on the logical switch named neutron-1c4c9a38...:
$ ovn-nbctl lport-list neutron-1c4c9a38-afae-40aa-a890-17cd460b314b
...
96432697-df3c-472a-b48a-9f844764d4bf
(neutron-e7c080ad-213d-4839-aa02-1af217a6548c)
We can also see that the proper MAC address was set on that port:
$ ovn-nbctl lport-get-macs neutron-e7c080ad-213d-4839-aa02-1af217a6548c
fa:16:3e:07:9e:68
--
Russell Bryant
__
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
--
Kevin Benton
__
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
Re: [openstack-dev] [Neutron] initial OVN testing
If that thing will have worked, I'll owe you a beer. Every time I debug OVS-neutron issues I want to cry. All that constant 'exec ovs-vsctl' stuff driving me mad because of the underengineering and overall inefficiency. I will definitively try it on 'reallife lab installation' with few compute hosts. On 03/27/2015 01:54 AM, Russell Bryant wrote: Gary and Kyle, I saw in my IRC backlog that you guys were briefly talking about testing the Neutron ovn ml2 driver. I suppose it's time to add some more code to the devstack integration to install the current ovn branch and set up ovsdb-server to serve up the right database for this. I'll try to work on that tomorrow. Of course, note that all we can set up right now is the northbound database. None of the code that reacts to updates to that database is merged yet. We can still go ahead and test our code and make sure the expected data makes it there, though. Here's some more detail about the pieces ... When I was writing ovn-nbctl [1], I was testing using ovs-sandbox. It's a script that sets up a handy development environment for ovs. It has ovn support if you pass the -o option [2]. To run it, it would be something like ... $ git clone https://github.com/openvswitch/ovs.git $ cd ovs $ git checkout ovn $ ./boot.sh $ ./configure $ make $ make SANDBOXFLAGS=-o sandbox From there you can run ovn-nbctl. Here's a script to demonstrate the various commands: https://gist.github.com/russellb/946953e8675063c0c756 To set this up outside of ovs-sandbox, you need to first create the OVN northbound database: $ ovsdb-tool create ovnnb.db ovs-git-tree/ovn/ovn-nb.ovsschema Then you need to tell ovsdb-server to use it. By default ovsdb-server will only serve up conf.db. It can take a list of dbs as positional arguments, though. You can see that's what the ovs-sandbox script is doing. So, you can either change the command used to start ovsdb-server on your system, or start up another instance of it with its own unix socket and tcp port. There was also a question on IRC about the format of the database option for the ML2 driver. The value is passed directly to ovn-nbctl. The format is the same as is used for ovs-vsctl (and probably others). When running in ovs-sandbox, ovn-nbctl's help output shows: --db=DATABASE connect to DATABASE (default: unix:/home/rbryant/src/ovs/tutorial/sandbox/db.sock) and further down, it provides some more detail: Active database connection methods: tcp:IP:PORT PORT at remote IP ssl:IP:PORT SSL PORT at remote IP unix:FILE Unix domain socket named FILE Passive database connection methods: ptcp:PORT[:IP] listen to TCP PORT on IP pssl:PORT[:IP] listen for SSL on PORT on IP punix:FILE listen on Unix domain socket FILE [1] http://openvswitch.org/pipermail/dev/2015-March/052757.html [2] http://openvswitch.org/pipermail/dev/2015-March/052353.html __ 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
Re: [openstack-dev] [Neutron] initial OVN testing
On 03/31/2015 01:09 PM, George Shuklin wrote: If that thing will have worked, I'll owe you a beer. Every time I debug OVS-neutron issues I want to cry. All that constant 'exec ovs-vsctl' stuff driving me mad because of the underengineering and overall inefficiency. I will definitively try it on 'reallife lab installation' with few compute hosts. Feel free to try it if you're interested in helping with development. It's not far enough along to actually use, though. The actual network connectivity part isn't wired up, which as it turns out, is kind of important. :-) The current goal is to have something working to demo and try by the Vancouver summit in May. -- Russell Bryant __ 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
Re: [openstack-dev] [Neutron] initial OVN testing
On 03/26/2015 07:54 PM, Russell Bryant wrote:
Gary and Kyle, I saw in my IRC backlog that you guys were briefly
talking about testing the Neutron ovn ml2 driver. I suppose it's time
to add some more code to the devstack integration to install the current
ovn branch and set up ovsdb-server to serve up the right database for
this. I'll try to work on that tomorrow. Of course, note that all we
can set up right now is the northbound database. None of the code that
reacts to updates to that database is merged yet. We can still go ahead
and test our code and make sure the expected data makes it there, though.
With help from Kyle Mestery, Gary Kotton, and Gal Sagie, some great
progress has been made over the last few days. Devstack support has
merged and the ML2 driver seems to be doing the right thing.
After devstack runs, you can see that the default networks created by
devstack are in the OVN db:
$ neutron net-list
+--+-+--+
| id | name| subnets
|
+--+-+--+
| 1c4c9a38-afae-40aa-a890-17cd460b314b | private |
115f27d1-5330-489e-b81f-e7f7da123a31 10.0.0.0/24 |
| 69fc7d7c-6906-43e7-b5e2-77c059cf4143 | public |
6b5c1597-4af8-4ad3-b28b-a4e83a07121b |
+--+-+--+
$ ovn-nbctl lswitch-list
47135494-6b36-4db9-8ced-3bdc9b711ca9
(neutron-1c4c9a38-afae-40aa-a890-17cd460b314b)
03494923-48cf-4af5-a391-ed48fe180c0b
(neutron-69fc7d7c-6906-43e7-b5e2-77c059cf4143)
$ ovn-nbctl lswitch-get-external-id
neutron-1c4c9a38-afae-40aa-a890-17cd460b314b
neutron:network_id=1c4c9a38-afae-40aa-a890-17cd460b314b
neutron:network_name=private
$ ovn-nbctl lswitch-get-external-id
neutron-69fc7d7c-6906-43e7-b5e2-77c059cf4143
neutron:network_id=69fc7d7c-6906-43e7-b5e2-77c059cf4143
neutron:network_name=public
You can also create ports and see those reflected in the OVN db:
$ neutron port-create 1c4c9a38-afae-40aa-a890-17cd460b314b
Created a new port:
+---+-+
| Field | Value
|
+---+-+
| admin_state_up| True
|
| allowed_address_pairs |
|
| binding:vnic_type | normal
|
| device_id |
|
| device_owner |
|
| fixed_ips | {subnet_id:
115f27d1-5330-489e-b81f-e7f7da123a31, ip_address: 10.0.0.3} |
| id| e7c080ad-213d-4839-aa02-1af217a6548c
|
| mac_address | fa:16:3e:07:9e:68
|
| name |
|
| network_id| 1c4c9a38-afae-40aa-a890-17cd460b314b
|
| security_groups | be68fd4e-48d8-46f2-8204-8a916ea6f348
|
| status| DOWN
|
| tenant_id | ed782253a54c4e0a8b46e275480896c9
|
+---+-+
List ports on the logical switch named neutron-1c4c9a38...:
$ ovn-nbctl lport-list neutron-1c4c9a38-afae-40aa-a890-17cd460b314b
...
96432697-df3c-472a-b48a-9f844764d4bf
(neutron-e7c080ad-213d-4839-aa02-1af217a6548c)
We can also see that the proper MAC address was set on that port:
$ ovn-nbctl lport-get-macs neutron-e7c080ad-213d-4839-aa02-1af217a6548c
fa:16:3e:07:9e:68
--
Russell Bryant
__
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
Re: [openstack-dev] [Neutron] initial OVN testing
Hi, I have added a few comments to the review and have a fixed a few issues that I have encountered along the way. I guess we can discuss on gerrit. Thanks Gary On 3/27/15, 12:54 AM, Russell Bryant rbry...@redhat.com wrote: Gary and Kyle, I saw in my IRC backlog that you guys were briefly talking about testing the Neutron ovn ml2 driver. I suppose it's time to add some more code to the devstack integration to install the current ovn branch and set up ovsdb-server to serve up the right database for this. I'll try to work on that tomorrow. Of course, note that all we can set up right now is the northbound database. None of the code that reacts to updates to that database is merged yet. We can still go ahead and test our code and make sure the expected data makes it there, though. Here's some more detail about the pieces ... When I was writing ovn-nbctl [1], I was testing using ovs-sandbox. It's a script that sets up a handy development environment for ovs. It has ovn support if you pass the -o option [2]. To run it, it would be something like ... $ git clone https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openvswitc h_ovs.gitd=AwIDaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZ BmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=cQf2n9s_bEj3_L162t5yzwj7_ElFgaXTUhr 2xEDAk0cs=l4rfZ9jttb06ukaHzMgz_RDzsQDjUEf25puSLaKEZZEe= $ cd ovs $ git checkout ovn $ ./boot.sh $ ./configure $ make $ make SANDBOXFLAGS=-o sandbox From there you can run ovn-nbctl. Here's a script to demonstrate the various commands: https://urldefense.proofpoint.com/v2/url?u=https-3A__gist.github.com_russe llb_946953e8675063c0c756d=AwIDaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtX t-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=cQf2n9s_bEj3_L162t5y zwj7_ElFgaXTUhr2xEDAk0cs=vG12ShRj8kDdsQLwzI-4_s0aG41duG-_wlTwR2jWpmke= To set this up outside of ovs-sandbox, you need to first create the OVN northbound database: $ ovsdb-tool create ovnnb.db ovs-git-tree/ovn/ovn-nb.ovsschema Then you need to tell ovsdb-server to use it. By default ovsdb-server will only serve up conf.db. It can take a list of dbs as positional arguments, though. You can see that's what the ovs-sandbox script is doing. So, you can either change the command used to start ovsdb-server on your system, or start up another instance of it with its own unix socket and tcp port. There was also a question on IRC about the format of the database option for the ML2 driver. The value is passed directly to ovn-nbctl. The format is the same as is used for ovs-vsctl (and probably others). When running in ovs-sandbox, ovn-nbctl's help output shows: --db=DATABASE connect to DATABASE (default: unix:/home/rbryant/src/ovs/tutorial/sandbox/db.sock) and further down, it provides some more detail: Active database connection methods: tcp:IP:PORT PORT at remote IP ssl:IP:PORT SSL PORT at remote IP unix:FILE Unix domain socket named FILE Passive database connection methods: ptcp:PORT[:IP] listen to TCP PORT on IP pssl:PORT[:IP] listen for SSL on PORT on IP punix:FILE listen on Unix domain socket FILE [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_piperm ail_dev_2015-2DMarch_052757.htmld=AwIDaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw- YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=cQf2n9s_bEj3 _L162t5yzwj7_ElFgaXTUhr2xEDAk0cs=NBPDQRkeI_pZKdXfwzZ11QKpjccl2wFKhVZr8rgK KCwe= [2] https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_piperm ail_dev_2015-2DMarch_052353.htmld=AwIDaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw- YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=cQf2n9s_bEj3 _L162t5yzwj7_ElFgaXTUhr2xEDAk0cs=36n_EGBEv4v5nS3DoHsBHfgCoJQxXB176pfnHnbt 8eIe= -- Russell Bryant __ 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
Re: [openstack-dev] [Neutron] initial OVN testing
Thanks for starting this Russell. Some answers inline. Salvatore On 27 March 2015 at 00:54, Russell Bryant rbry...@redhat.com wrote: Gary and Kyle, I saw in my IRC backlog that you guys were briefly talking about testing the Neutron ovn ml2 driver. I suppose it's time to add some more code to the devstack integration to install the current ovn branch and set up ovsdb-server to serve up the right database for this. I'll try to work on that tomorrow. Of course, note that all we can set up right now is the northbound database. None of the code that reacts to updates to that database is merged yet. We can still go ahead and test our code and make sure the expected data makes it there, though. In theory this should be enough! Here's some more detail about the pieces ... When I was writing ovn-nbctl [1], I was testing using ovs-sandbox. It's a script that sets up a handy development environment for ovs. It has ovn support if you pass the -o option [2]. To run it, it would be something like ... $ git clone https://github.com/openvswitch/ovs.git $ cd ovs $ git checkout ovn $ ./boot.sh $ ./configure $ make $ make SANDBOXFLAGS=-o sandbox From there you can run ovn-nbctl. Here's a script to demonstrate the various commands: https://gist.github.com/russellb/946953e8675063c0c756 To set this up outside of ovs-sandbox, you need to first create the OVN northbound database: $ ovsdb-tool create ovnnb.db ovs-git-tree/ovn/ovn-nb.ovsschema Then you need to tell ovsdb-server to use it. By default ovsdb-server will only serve up conf.db. It can take a list of dbs as positional arguments, though. You can see that's what the ovs-sandbox script is doing. Do you reckon this steps should be performed by devstack (or to be more precise the neutron-ovn devstack plugin that we should develop) or shall we assume OVN is already configured? For me both ways work. However some developers (like Russell I guess) will be working both on OVN and the neutron plugin, so maybe I'm not sure having devstack doing the OVN setup might be helpful for them; on the other hand this might come somewhat handy for setting up CI jobs. So, you can either change the command used to start ovsdb-server on your system, or start up another instance of it with its own unix socket and tcp port. There was also a question on IRC about the format of the database option for the ML2 driver. The value is passed directly to ovn-nbctl. The format is the same as is used for ovs-vsctl (and probably others). In the ovs-dev mailing list you said (correctly imo) that openstack should not use nbctl but rather talk directly through ovsdb with the OVN controller. It seems here you're stating the ML2 driver will pass down the database connection info to nbctl. I don't know if that's your intention, but I would rather avoid having another plugin that uses command line for everything.This would save us the pain of having to scrape through command output, and more importantly will avoid the overhead associated with rootwrap (daemonized or not). When running in ovs-sandbox, ovn-nbctl's help output shows: --db=DATABASE connect to DATABASE (default: unix:/home/rbryant/src/ovs/tutorial/sandbox/db.sock) and further down, it provides some more detail: Active database connection methods: tcp:IP:PORT PORT at remote IP ssl:IP:PORT SSL PORT at remote IP unix:FILE Unix domain socket named FILE Passive database connection methods: ptcp:PORT[:IP] listen to TCP PORT on IP pssl:PORT[:IP] listen for SSL on PORT on IP punix:FILE listen on Unix domain socket FILE [1] http://openvswitch.org/pipermail/dev/2015-March/052757.html [2] http://openvswitch.org/pipermail/dev/2015-March/052353.html -- Russell Bryant __ 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 __ 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
[openstack-dev] [Neutron] initial OVN testing
Gary and Kyle, I saw in my IRC backlog that you guys were briefly talking about testing the Neutron ovn ml2 driver. I suppose it's time to add some more code to the devstack integration to install the current ovn branch and set up ovsdb-server to serve up the right database for this. I'll try to work on that tomorrow. Of course, note that all we can set up right now is the northbound database. None of the code that reacts to updates to that database is merged yet. We can still go ahead and test our code and make sure the expected data makes it there, though. Here's some more detail about the pieces ... When I was writing ovn-nbctl [1], I was testing using ovs-sandbox. It's a script that sets up a handy development environment for ovs. It has ovn support if you pass the -o option [2]. To run it, it would be something like ... $ git clone https://github.com/openvswitch/ovs.git $ cd ovs $ git checkout ovn $ ./boot.sh $ ./configure $ make $ make SANDBOXFLAGS=-o sandbox From there you can run ovn-nbctl. Here's a script to demonstrate the various commands: https://gist.github.com/russellb/946953e8675063c0c756 To set this up outside of ovs-sandbox, you need to first create the OVN northbound database: $ ovsdb-tool create ovnnb.db ovs-git-tree/ovn/ovn-nb.ovsschema Then you need to tell ovsdb-server to use it. By default ovsdb-server will only serve up conf.db. It can take a list of dbs as positional arguments, though. You can see that's what the ovs-sandbox script is doing. So, you can either change the command used to start ovsdb-server on your system, or start up another instance of it with its own unix socket and tcp port. There was also a question on IRC about the format of the database option for the ML2 driver. The value is passed directly to ovn-nbctl. The format is the same as is used for ovs-vsctl (and probably others). When running in ovs-sandbox, ovn-nbctl's help output shows: --db=DATABASE connect to DATABASE (default: unix:/home/rbryant/src/ovs/tutorial/sandbox/db.sock) and further down, it provides some more detail: Active database connection methods: tcp:IP:PORT PORT at remote IP ssl:IP:PORT SSL PORT at remote IP unix:FILE Unix domain socket named FILE Passive database connection methods: ptcp:PORT[:IP] listen to TCP PORT on IP pssl:PORT[:IP] listen for SSL on PORT on IP punix:FILE listen on Unix domain socket FILE [1] http://openvswitch.org/pipermail/dev/2015-March/052757.html [2] http://openvswitch.org/pipermail/dev/2015-March/052353.html -- Russell Bryant __ 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
Re: [openstack-dev] [Neutron] initial OVN testing
On 03/26/2015 08:22 PM, Salvatore Orlando wrote: To set this up outside of ovs-sandbox, you need to first create the OVN northbound database: $ ovsdb-tool create ovnnb.db ovs-git-tree/ovn/ovn-nb.ovsschema Then you need to tell ovsdb-server to use it. By default ovsdb-server will only serve up conf.db. It can take a list of dbs as positional arguments, though. You can see that's what the ovs-sandbox script is doing. Do you reckon this steps should be performed by devstack (or to be more precise the neutron-ovn devstack plugin that we should develop) or shall we assume OVN is already configured? For me both ways work. However some developers (like Russell I guess) will be working both on OVN and the neutron plugin, so maybe I'm not sure having devstack doing the OVN setup might be helpful for them; on the other hand this might come somewhat handy for setting up CI jobs. I think automating in devstack makes sense. Right now I would want it to feel like the OpenStack components in devstack. I want an ovs git tree that I can hack on along side my OpenStack git trees and have everything started up using the current state of the code. Automating that should serve both the dev and test cases. I'm sure the automation will evolve over time when it's eventually packaged and so forth. For now it's going to be a fast moving target straight from git. So, you can either change the command used to start ovsdb-server on your system, or start up another instance of it with its own unix socket and tcp port. There was also a question on IRC about the format of the database option for the ML2 driver. The value is passed directly to ovn-nbctl. The format is the same as is used for ovs-vsctl (and probably others). In the ovs-dev mailing list you said (correctly imo) that openstack should not use nbctl but rather talk directly through ovsdb with the OVN controller. It seems here you're stating the ML2 driver will pass down the database connection info to nbctl. I don't know if that's your intention, but I would rather avoid having another plugin that uses command line for everything.This would save us the pain of having to scrape through command output, and more importantly will avoid the overhead associated with rootwrap (daemonized or not). I absolutely agree. The current use of the utility is just a make it work ASAP approach for POC purposes. The real goal is to use ovsdb directly. I've been talking to Terry about using his work in Neutron here, as well. However, I don't want to block on that part for getting things up and running in a first iteration. -- Russell Bryant __ 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
