)]}'
{"specs/newton/approved/vif-vhost-user-ovs-fallback.rst":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e43cf7f935d0f61571715b821d38d0011aef7d51","unresolved":false,"context_lines":[{"line_number":53,"context_line":""},{"line_number":54,"context_line":"    ovs-vsctl get Bridge br-int datapath_type"},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"If the result of this command is \"netdev\", we should proceed with a vhost-user"},{"line_number":57,"context_line":"port.  Otherwise, we should fall back to the behavior of VIF_TYPE_OVS."},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"Since this check is easy to do, the changes required to implement this are"},{"line_number":60,"context_line":"fairly minimal."}],"source_content_type":"text/x-rst","patch_set":1,"id":"dae33548_41177344","line":57,"range":{"start_line":56,"start_character":0,"end_line":57,"end_character":70},"updated":"2016-02-19 00:13:06.000000000","message":"this is not sufficient to tell if vhost-user should be used.\nin addtion to this you need to check if the dpdkvhostuser interface type is present in the Open_vSwitch table.\n\nthe following check would work.\n\n[ $(sudo ovs-vsctl --column\u003dname find Bridge name\u003dbr-int datapath_type\u003dnetdev | wc -l) \u003d\u003d \"1\" ] \u0026\u0026 [ $(sudo ovs-vsctl --column\u003ddatapath_type find Open_vSwitch \"iface_types{\u003e}dpdkvhostuser\" | wc -l ) \u003d\u003d \"1\" ] ; echo $?\n\nyou can drop the echo and just just read the retrun code.\nit will be 0 if the configuration supports vhost-user or 1 otherwise.\n\nhaving said that its probably clean to do in python but its doable in bash too.","commit_id":"4c185efaf18b7b7967dbd6744219c817eeb7df25"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"b0cf8f52e861bee48aafbcf15e1c7d4ce85e326a","unresolved":false,"context_lines":[{"line_number":58,"context_line":""},{"line_number":59,"context_line":"Since this check is easy to do, the changes required to implement this are"},{"line_number":60,"context_line":"fairly minimal."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"Alternatives"},{"line_number":63,"context_line":"------------"},{"line_number":64,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"dae33548_c9d97785","line":61,"updated":"2016-02-16 19:48:24.000000000","message":"This is really not at all in line with the direction we\u0027re trying to go with integration of the os-vif project in Nova. What is particularly unpleasant about this approach is that its inventing a one-off special case solution that only works for ovs and doesn\u0027t solve the problem for non-ovs scenarios.\n\nThe design of os-vif is intended to allow Nova to notify Neutron upfront about what VIF types and plugins it is capable of supporting.\n\nWith os-vif, Nova will have 1 or more plugins available for configuring host networking. Each plugin class will support 1 or more VIF config classes used to configure guest networking. Crucially the set of support VIF types can be dynamically determined.\n\nSo for example, a single plugin would be able to report that it supports the VIFVHostUser  and VIFOpenVSwitch config classes, vs only the VIFOpenVSwitch class.\n\nSee the \u0027describe\u0027 method in the os-vif plugin class implmenentations. For example the ovs_hybrid plugin class says it supports the VIFOpenVSwitch config class between versions 1.0 and 1.0\n\nhttps://github.com/openstack/os-vif/blob/master/vif_plug_ovs/ovs_hybrid.py#L58\n\nIn Mitaka Nova aims to convert its internal VIF handling to use os-vif. In this world, Nova still receives the traditional VIF type + port binding information from Neutron and then turns that into a VIF plugin and VIF config class based on os-vif.\n\nIn Newton we want to extend that so that Neutron directly passes Nova the desired os-vif plugin + a serialized VIF config class.  As part of this integration, Nova would enumerate all plugins it has, and call their describe methods, and then pass all this data across to Neutron.\n\nSo for example, Nova might pass Neutron something like this:\n\n  plugins \u003d {\n    \"ovs_hybrid\" : {\n       vif_info: [\n         {\n            vif_class: \"VIFOpenVSwitch\",\n            min_version: \"1.0\"\n            max_version: \"1.0\n         }\n       ]\n    }\n    \"vhostuser\" : {\n       vif_info: [\n         {\n            vif_class: \"VIFVHostUser\",\n            min_version: \"1.0\"\n            max_version: \"1.0\n         }\n         {\n            vif_class: \"VIFOpenVSwitch\",\n            min_version: \"1.0\"\n            max_version: \"1.0\n         }\n       ]\n    }\n  }\n\nSo Neutron can see that Nova supports a \u0027vhostuser\u0027 plugin and that it is able to use both VIFVHostUser and VIFOpenVSwitch configuration approaches.\n\nOn a host lacking vhost-user support, Nova would *not* report VIFVHostUser config support. So Neutron would know to send Nova a VIFOpenVSwitch based config.\n\nThus we get a generic mechanism for negotiating both which plugin to use, as well as which configuration approach to use with the plugin, instead of something that\u0027s totally ovs-specific as described in this spec.","commit_id":"4c185efaf18b7b7967dbd6744219c817eeb7df25"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"28cfb191c17cebb3b4e0cef1a4f81cea7aa986e7","unresolved":false,"context_lines":[{"line_number":58,"context_line":""},{"line_number":59,"context_line":"Since this check is easy to do, the changes required to implement this are"},{"line_number":60,"context_line":"fairly minimal."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"Alternatives"},{"line_number":63,"context_line":"------------"},{"line_number":64,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"dae33548_ecba8409","line":61,"in_reply_to":"dae33548_2c08f12b","updated":"2016-02-16 21:50:41.000000000","message":"what part of the API do you see Nova passing over the plugins info to Neutron?","commit_id":"4c185efaf18b7b7967dbd6744219c817eeb7df25"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"f5f27777533a280641bf371c672c5794d7678d0c","unresolved":false,"context_lines":[{"line_number":58,"context_line":""},{"line_number":59,"context_line":"Since this check is easy to do, the changes required to implement this are"},{"line_number":60,"context_line":"fairly minimal."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"Alternatives"},{"line_number":63,"context_line":"------------"},{"line_number":64,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"dae33548_2c08f12b","line":61,"in_reply_to":"dae33548_acb521ef","updated":"2016-02-16 20:10:27.000000000","message":"Thanks for the feedback.  I\u0027m happy to throw this away, I just want to solve the problem.  What you describe does sound nicer.\n\nHowever, I\u0027m not sure the approach you describe accomplishes the exact same thing.  The same system will be able to support both OVS with the kernel datapath and the DPDK datapath.  Determining whether vhost-user should be used depends on bridge-specific configuration.  The code could check the ovs bridge specified in nova.conf, but support for allowing Neutron to specify the OVS bridge via vif_details was recently added.","commit_id":"4c185efaf18b7b7967dbd6744219c817eeb7df25"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"1792aff0a366bd8dbe286715d8fe5a3f9168aac0","unresolved":false,"context_lines":[{"line_number":58,"context_line":""},{"line_number":59,"context_line":"Since this check is easy to do, the changes required to implement this are"},{"line_number":60,"context_line":"fairly minimal."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"Alternatives"},{"line_number":63,"context_line":"------------"},{"line_number":64,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"dae33548_acb521ef","line":61,"in_reply_to":"dae33548_c9d97785","updated":"2016-02-16 19:57:57.000000000","message":"I should also say from Nova\u0027s POV, in Newton we\u0027re likely not going to want to accept anymore additions to the vif details data for existing VIF types. We want to aim to focus 100% on working with Neutron to be 100% converted to using os-vif, and not distract ourselves changing legacy data.","commit_id":"4c185efaf18b7b7967dbd6744219c817eeb7df25"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e43cf7f935d0f61571715b821d38d0011aef7d51","unresolved":false,"context_lines":[{"line_number":58,"context_line":""},{"line_number":59,"context_line":"Since this check is easy to do, the changes required to implement this are"},{"line_number":60,"context_line":"fairly minimal."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"Alternatives"},{"line_number":63,"context_line":"------------"},{"line_number":64,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"dae33548_610277b5","line":61,"in_reply_to":"dae33548_ecba8409","updated":"2016-02-19 00:13:06.000000000","message":"i had a conversation with ian wells at the vancover summit on this topic\n\nthis spec was created to capture the details\nhttps://review.openstack.org/#/c/190917/7/specs/mitaka/approved/nova-neutron-binding-negotiation.rst\n\nwe suggested extending the vif binding_profile to capture\na list of preferred_binding_types which nova would add to the port when it asks neutron to bind it.\n\n\"binding_profile\": {\n        ... current information\n        \"preferred_binding_types\": [\"vhostuser\", \"ovs\", \"ivs\"]\n    }","commit_id":"4c185efaf18b7b7967dbd6744219c817eeb7df25"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e43cf7f935d0f61571715b821d38d0011aef7d51","unresolved":false,"context_lines":[{"line_number":59,"context_line":"Since this check is easy to do, the changes required to implement this are"},{"line_number":60,"context_line":"fairly minimal."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"Alternatives"},{"line_number":63,"context_line":"------------"},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"1) Require every Neutron backend system to determine if DPDK is in use, report"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dae33548_a415ac9c","line":62,"range":{"start_line":62,"start_character":0,"end_line":62,"end_character":12},"updated":"2016-02-19 00:13:06.000000000","message":"so i have mixed felling about this.\n\n as i said above we proposed something similar 2 years ago and nova rejected it.\n\nif our original propoasl for a config value that the local nova-compute agent reads had been accepted we would not have had to spend 18 months modifying ovs,neutron odl and may other project to enable vhost-user support.\n\nwhile the taught of essintailly reverting to an implementation similar to what we proposed 2 years ago is somewhat unpalatable\ngive the work that has been invested to get to our current state of\nvhost-user support there is perhaps a nice middle ground.\n\ni agree with the current direction of OS-vif in that i strongly belive it should not be respocible for generating the vm config.\non the other hand i also feel that OS-vif should be able to influence what vif is selected.\n\nmy alternative proposal would be the following:\n\t- extend the os-vif api with one addtional public entry point getPreferedVifBindings()\n\t\tgetPreferedVifBindings() will retrun a map of VIF_TYPE -\u003e set of vif_plug plugins availble\n\t\ton the current host with versions.\n\t- modify nova to call getPreferedVifBindings before it calls neutron to bind the port and store\n\t\tthe result in the port binding_profile\n\t- call neutron to bind the port before generating the vm config (libvirt xml or equivalent for other hypervisor)\n\t\n\t- modify neutron to read the preferred_binding_types for the port binding_profile and select\n\t\tone as part of the port binding.\n\t\tat this point in neutron can tell its backend what the binding details for the interface will be.\n\t\te.g. it can create the logical port in the ovn northdb or odl api.\n\t\tnetworking-ovn could have very simple logic of if vhostuser is in the preferred_binding_types \n\t\tuse it if not use the ovs_vif similar to what is discribed in \n\t\thttps://review.openstack.org/#/c/190917/7/specs/mitaka/approved/nova-neutron-binding-negotiation.rst\n\t\tas this is per port it also solve the coexistance issue.\n\t\n\t- once the port is bound  nova can read the finalised port details from the responce to the port bind call\n\t  and generate the hypervisor specifc vm config e.g. libvirt xml using this infomation.\n\t  \n\t- nova can then boot the vm and the neutron backends will wire up the interface when it is added to the backend.\n\t\n\tthis is a extreamly generic solution that will be much more robust then what we have today.\n\t\n\tin addtion to the 1 new public entrypoint in os-vif 1 addtional mandatroy method would be added to\n\teach os-vif plug driver, getSupportedVIF() the implementation of which is driver specific.\n\t\n\ta simply plug driver e.g. linux bridge could simply have a hardcoded list of one value. \n\tthe ovs plug diriver could return a dynamic list  based on query ovs do determin if vhost-user is supported.\n\t\n\tthe os-vif init would be extended to query each plug driver that is loaded on the local node and build the maping\n\tform vif_type to plug driver.(a default dict of sets as discribed above)\n\tthe getPreferedVifBindings() will simply retrun this pre initalised set.\n\t\n\tby placing this logic in os-vif  we have a clean separation of concerns. nova deals with hypervisor configuration.\n\tneutron deals with configure ing the network backed control plane either via an agent or sdn controller \n\tand os-vif deals with plug drivers and vif_types. as the getPreferedVifBindings would be part of the public api of\n\tthe public api for os-vif any other project such as neutron,magnum or ironic could reuse it if they had a need.\n\t\n\tthis is a much larger and more generic change but i would prefer to fix this \n\tproperly once then have to fix it over and over again.","commit_id":"4c185efaf18b7b7967dbd6744219c817eeb7df25"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e43cf7f935d0f61571715b821d38d0011aef7d51","unresolved":false,"context_lines":[{"line_number":72,"context_line":""},{"line_number":73,"context_line":"   https://review.openstack.org/#/c/215612/"},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"   Had a mechanism like \"ovs_fallback\" been available, *none* of that work"},{"line_number":76,"context_line":"   would have been required."},{"line_number":77,"context_line":""},{"line_number":78,"context_line":"   The OVN backend for Neutron is now faced with the same situation.  We can do"},{"line_number":79,"context_line":"   extensive work in OVN and the OVN plugin for Neutron, but this change would"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dae33548_619277f7","line":76,"range":{"start_line":75,"start_character":3,"end_line":76,"end_character":28},"updated":"2016-02-19 00:13:06.000000000","message":"that is not quite true however its not wrong either.\n\nif networking-odl ever want to support backend other then ovs the majoriy of the code we added would be required.\n\non the other hand the original implementation of userpaces vhost we create for icehouse used a single config value in the nova compute agent conf to select either kernel vhost or vhost-user ( or its precursor dpdk userspace vhost as was supported at the time).\n\nif that original patch which we submitted upstream for juno had been accepted we would have never had to modify ovs,odl,networking-ovs-dpdk,networking-odl,networking-ovn and neutron to enable vhost-user support in openstack.\n\nwhile i understand why neutron currently decides what vif_type to use it means that every neutron backend that can manage ovs with dpdk has to be enabled separately instead of once in nova.\n\nby the way if someting like this was added i would prefer if it was not a fallback in the sense of try one then the other.\nif it determines that it should use vhostuser and the vm fails to boot it would be better to reschedule then retry local when the claims based scheduler is completed.","commit_id":"4c185efaf18b7b7967dbd6744219c817eeb7df25"}]}