Re: [openstack-dev] [nova][NFV] VIF_VHOSTUSER

2014-09-03 Thread Luke Gorrie
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

2014-09-01 Thread loy wolfe
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

2014-08-31 Thread Itzik Brown


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


Re: [openstack-dev] [nova][NFV] VIF_VHOSTUSER

2014-08-30 Thread Ian Wells
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.



On 27 August 2014 07:30, Daniel P. Berrange berra...@redhat.com wrote:

 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

___
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

2014-08-27 Thread Daniel P. Berrange
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