Hi I would like to bring up a recurring problem that Has arisen several times with enabling new ovs features in OpenStack.
OpenStack neutron supports many different network backend Including ovs which is currently the most common . As OpenStack has to support multiple versions of ovs both to provide Multi distro support and to support rolling upgrades new ovs features That are consumed in openstack must be enabled dynamically based on the Capabilities of the vswitch on the target server. An example of this today is vhost-user support. if ovs is compiled with dpdk support And started with dpdk enabled the ifaces_types field in the Open_vSwitch table will Contain the dpdk_vhostuser port type. If the dpdk_vhostuser port type is found and the bridges Datapath type Is netdev then vhost-user is enabled for that platform in neutron. There are many other feature that cannot be detected remotely today. The ovs FAQ lists a number of features that are available on different data paths that openstack and other Systems may care to know about so that it can use that feature when present and take appropriate action when not. e.g. place vm on a different host running a different ovs version or fallback to a different code path if a new feature is not available https://github.com/openvswitch/ovs/blob/master/FAQ.md#q-are-all-features-available-with-all-datapaths what I would like to ask is if we can introduce a new ovsdb table to declare the features available in the current ovs version. This would involve converting the current tables in the FAQ feature section in to static entries in the ovsdb schema in a new Feature table. Each entry in the table would be readonly and the table can be upgraded in each release by ovsdb-tool convert to migrate/upgreade The schema of the current db. Note the reason I am suggesting using the ovsdb to declare the features is that for odl and to a less extent ovn and openstack The ovsdb is the only interface that can be used to interact with the vswitch remotely. In the special case of odl neither odl or openstack neutron have an agent on the server running ovs so only ovsdb and openflow can be used. As a result tools such as ovs-appctl or any of the other ovs-* tools cannot be used to support this usecase. Currently there are 3 feature that will require this or a similar feature to enable in openstack. Those feature are: Vhost-user reconnect / vhost- user qemu:server dpdk:client mode UserSpace jumbo frames support Connection tracking Other features that this would be required for in the future include ovs NAT,QOS polices,NSH and any other feature that is not Enabled on all datapath concurrently. I would expect that ovn would need a subset of this information to be reported in the chassis table also in the future to enable more advanced use cases. Regards Sean. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
