Re: [openstack-dev] [nova][NFV] VIF_VHOSTUSER
On 1 September 2014 09:10, loy wolfe loywo...@gmail.com wrote: If the neutron side MD is just for snabbswitch, then I thinks there is no change to be merged into the tree. Maybe we can learn from sriov nic, although backend is vendor specific, but the MD is generic, can support snabb, dpdkovs, ans other userspace vswitch, etc. That is an interesting idea. The Snabb mech driver simply asks Neutron/Nova to bind the port with VIF_VHOSTUSER. If this is the requirement for other drivers too then it would seem that we have good potential for sharing code. Perhaps we could rename mech_snabb to mech_vhostuser, like we have already renamed the VIF code. Going forward we would like the Snabb driver to become more mainstream in the way it manages its agent on the compute host. Currently we use a simple brute force approach [1] that is intended to protect us from synchronisation bugs (race conditions) and be compatible with multiple versions of OpenStack (e.g. the one we deploy with + the one we upstream towards). If we did not have to support a production version based on a stable OpenStack release then we might have been less conservative here. Cheers, -Luke [1] Snabb NFV architecture: https://github.com/SnabbCo/snabbswitch/wiki/Snabb-NFV-Architecture ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][NFV] VIF_VHOSTUSER
If the neutron side MD is just for snabbswitch, then I thinks there is no change to be merged into the tree. Maybe we can learn from sriov nic, although backend is vendor specific, but the MD is generic, can support snabb, dpdkovs, ans other userspace vswitch, etc. As the reference implementation CI, the snabb can work in a very simple mode without need for agent (just as agentless sriov veb nic) On Sun, Aug 31, 2014 at 9:36 PM, Itzik Brown itz...@dev.mellanox.co.il wrote: On 8/30/2014 11:22 PM, Ian Wells wrote: The problem here is that you've removed the vif_driver option and now you're preventing the inclusion of named VIF types into the generic driver, which means that rather than adding a package to an installation to add support for a VIF driver it's now necessary to change the Nova code (and repackage it, or - ew - patch it in place after installation). I understand where you're coming from but unfortunately the two changes together make things very awkward. Granted that vif_driver needed to go away - it was the wrong level of code and the actual value was coming from the wrong place anyway (nova config and not Neutron) - but it's been removed without a suitable substitute. It's a little late for a feature for Juno, but I think we need to write something discovers VIF types installed on the system. That way you can add a new VIF type to Nova by deploying a package (and perhaps naming it in config as an available selection to offer to Neutron) *without* changing the Nova tree itself. In the meantime, I recommend you consult with the Neutron cores and see if you can make an exception for the VHOSTUSER driver for the current timescale. -- Ian. I Agree with Ian. My understanding from a conversation a month ago was that there would be an alternative to the deprecated config option. As far as I understand now there is no such alternative in Juno and in case that one has an out of the tree VIF Driver he'll be left out with a broken solution. What do you say about an option of reverting the change? Anyway It might be a good idea to discuss propositions to address this issue towards Kilo summit. BR, Itzik ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][NFV] VIF_VHOSTUSER
On 8/30/2014 11:22 PM, Ian Wells wrote: The problem here is that you've removed the vif_driver option and now you're preventing the inclusion of named VIF types into the generic driver, which means that rather than adding a package to an installation to add support for a VIF driver it's now necessary to change the Nova code (and repackage it, or - ew - patch it in place after installation). I understand where you're coming from but unfortunately the two changes together make things very awkward. Granted that vif_driver needed to go away - it was the wrong level of code and the actual value was coming from the wrong place anyway (nova config and not Neutron) - but it's been removed without a suitable substitute. It's a little late for a feature for Juno, but I think we need to write something discovers VIF types installed on the system. That way you can add a new VIF type to Nova by deploying a package (and perhaps naming it in config as an available selection to offer to Neutron) *without* changing the Nova tree itself. In the meantime, I recommend you consult with the Neutron cores and see if you can make an exception for the VHOSTUSER driver for the current timescale. -- Ian. I Agree with Ian. My understanding from a conversation a month ago was that there would be an alternative to the deprecated config option. As far as I understand now there is no such alternative in Juno and in case that one has an out of the tree VIF Driver he'll be left out with a broken solution. What do you say about an option of reverting the change? Anyway It might be a good idea to discuss propositions to address this issue towards Kilo summit. BR, Itzik ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova][NFV] VIF_VHOSTUSER
Howdy! I am writing to ask whether it will be possible to merge VIF_VHOSTUSER [1] in Juno? VIF_VHOSTUSER adds support for a QEMU 2.1 has a feature called vhost-user [2] that allows a guest to do Virtio-net I/O via a userspace vswitch. This makes it convenient to deploy new vswitches that are optimized for NFV workloads, of which there are now several both open source and proprietary. The complication is that we have no CI coverage for this feature in Juno. Originally we had anticipated merging a Neutron driver that would exercise vhost-user but the Neutron core team requested that we develop that outside of the Neutron tree for the time being instead [3]. We are hoping that the Nova team will be willing to merge the feature even so. Within the NFV subgroup it would help us to share more code with each other and also be good for our morale :) particularly as the QEMU work was done especially for use with OpenStack. Cheers, -Luke [1] https://review.openstack.org/#/c/96140/ [2] http://www.virtualopensystems.com/en/solutions/guides/snabbswitch-qemu/ [3] https://review.openstack.org/#/c/116476/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][NFV] VIF_VHOSTUSER
On Wed, Aug 27, 2014 at 04:06:25PM +0200, Luke Gorrie wrote: Howdy! I am writing to ask whether it will be possible to merge VIF_VHOSTUSER [1] in Juno? VIF_VHOSTUSER adds support for a QEMU 2.1 has a feature called vhost-user [2] that allows a guest to do Virtio-net I/O via a userspace vswitch. This makes it convenient to deploy new vswitches that are optimized for NFV workloads, of which there are now several both open source and proprietary. The complication is that we have no CI coverage for this feature in Juno. Originally we had anticipated merging a Neutron driver that would exercise vhost-user but the Neutron core team requested that we develop that outside of the Neutron tree for the time being instead [3]. We are hoping that the Nova team will be willing to merge the feature even so. Within the NFV subgroup it would help us to share more code with each other and also be good for our morale :) particularly as the QEMU work was done especially for use with OpenStack. Our general rule for accepting new VIF drivers in Nova is that Neutron should have accepted the corresponding other half of VIF driver, since nova does not want to add support for things that are not in-tree for Neutron. In this case addign the new VIF driver involves defining a new VIF type and corresponding metadata associated with it. This metadata is part of the public API definition, to be passed from Neutron to Nova during VIF plugging and so IMHO this has to be agreed upon and defined in tree for Neutron Nova. So even if the VIF driver in Neutron were to live out of tree, at a very minimum I'd expect the VIF_VHOSTUSER part to be specified in-tree to Neutron, so that Nova has a defined interface it can rely on. So based on this policy, my recommendation would be to keep the Nova VIF support out of tree in your own branch of Nova codebase until Neutron team are willing to accept their half of the driver. In cases like this I think Nova Neutron need to work together to agree on acceptance/rejection of the proposed feature. Having one project accept it and the other project reject, without them talking to each other is not a good position to be in. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
