Re: [openstack-dev] [nova][neutron] Boundary between Nova and Neutron involvement in network setup?

2014-12-10 Thread Kevin Benton
What would the port binding operation do in this case? Just mark the port
as bound and nothing else?

On Wed, Dec 10, 2014 at 12:48 AM, henry hly henry4...@gmail.com wrote:

 Hi Kevin,

 Does it make sense to introduce GeneralvSwitch MD, working with
 VIF_TYPE_TAP? It just do very simple port bind just like OVS and
 bridge. Then anyone can implement their backend and agent without
 patch neutron drivers.

 Best Regards
 Henry

 On Fri, Dec 5, 2014 at 4:23 PM, Kevin Benton blak...@gmail.com wrote:
  I see the difference now.
  The main concern I see with the NOOP type is that creating the virtual
  interface could require different logic for certain hypervisors. In that
  case Neutron would now have to know things about nova and to me it seems
  like that's slightly too far the other direction.
 
  On Thu, Dec 4, 2014 at 8:00 AM, Neil Jerram neil.jer...@metaswitch.com
  wrote:
 
  Kevin Benton blak...@gmail.com writes:
 
   What you are proposing sounds very reasonable. If I understand
   correctly, the idea is to make Nova just create the TAP device and get
   it attached to the VM and leave it 'unplugged'. This would work well
   and might eliminate the need for some drivers. I see no reason to
   block adding a VIF type that does this.
 
  I was actually floating a slightly more radical option than that: the
  idea that there is a VIF type (VIF_TYPE_NOOP) for which Nova does
  absolutely _nothing_, not even create the TAP device.
 
  (My pending Nova spec at https://review.openstack.org/#/c/130732/
  proposes VIF_TYPE_TAP, for which Nova _does_ creates the TAP device, but
  then does nothing else - i.e. exactly what you've described just above.
  But in this email thread I was musing about going even further, towards
  providing a platform for future networking experimentation where Nova
  isn't involved at all in the networking setup logic.)
 
   However, there is a good reason that the VIF type for some OVS-based
   deployments require this type of setup. The vSwitches are connected to
   a central controller using openflow (or ovsdb) which configures
   forwarding rules/etc. Therefore they don't have any agents running on
   the compute nodes from the Neutron side to perform the step of getting
   the interface plugged into the vSwitch in the first place. For this
   reason, we will still need both types of VIFs.
 
  Thanks.  I'm not advocating that existing VIF types should be removed,
  though - rather wondering if similar function could in principle be
  implemented without Nova VIF plugging - or what that would take.
 
  For example, suppose someone came along and wanted to implement a new
  OVS-like networking infrastructure?  In principle could they do that
  without having to enhance the Nova VIF driver code?  I think at the
  moment they couldn't, but that they would be able to if VIF_TYPE_NOOP
  (or possibly VIF_TYPE_TAP) was already in place.  In principle I think
  it would then be possible for the new implementation to specify
  VIF_TYPE_NOOP to Nova, and to provide a Neutron agent that does the kind
  of configuration and vSwitch plugging that you've described above.
 
  Does that sound correct, or am I missing something else?
 
   1 .When the port is created in the Neutron DB, and handled (bound
   etc.)
   by the plugin and/or mechanism driver, the TAP device name is already
   present at that time.
  
   This is backwards. The tap device name is derived from the port ID, so
   the port has already been created in Neutron at that point. It is just
   unbound. The steps are roughly as follows: Nova calls neutron for a
   port, Nova creates/plugs VIF based on port, Nova updates port on
   Neutron, Neutron binds the port and notifies agent/plugin/whatever to
   finish the plumbing, Neutron notifies Nova that port is active, Nova
   unfreezes the VM.
  
   None of that should be affected by what you are proposing. The only
   difference is that your Neutron agent would also perform the
   'plugging' operation.
 
  Agreed - but thanks for clarifying the exact sequence of events.
 
  I wonder if what I'm describing (either VIF_TYPE_NOOP or VIF_TYPE_TAP)
  might fit as part of the Nova-network/Neutron Migration priority
  that's just been announced for Kilo.  I'm aware that a part of that
  priority is concerned with live migration, but perhaps it could also
  include the goal of future networking work not having to touch Nova
  code?
 
  Regards,
  Neil
 
 
 
 
  --
  Kevin Benton
 
  ___
  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




-- 
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org

Re: [openstack-dev] [nova][neutron] Boundary between Nova and Neutron involvement in network setup?

2014-12-10 Thread henry hly
On Thu, Dec 11, 2014 at 12:36 AM, Kevin Benton blak...@gmail.com wrote:
 What would the port binding operation do in this case? Just mark the port as
 bound and nothing else?


Also to set the vif type to tap, but don't care what the real backend switch is.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova][neutron] Boundary between Nova and Neutron involvement in network setup?

2014-12-09 Thread henry hly
Hi Kevin,

Does it make sense to introduce GeneralvSwitch MD, working with
VIF_TYPE_TAP? It just do very simple port bind just like OVS and
bridge. Then anyone can implement their backend and agent without
patch neutron drivers.

Best Regards
Henry

On Fri, Dec 5, 2014 at 4:23 PM, Kevin Benton blak...@gmail.com wrote:
 I see the difference now.
 The main concern I see with the NOOP type is that creating the virtual
 interface could require different logic for certain hypervisors. In that
 case Neutron would now have to know things about nova and to me it seems
 like that's slightly too far the other direction.

 On Thu, Dec 4, 2014 at 8:00 AM, Neil Jerram neil.jer...@metaswitch.com
 wrote:

 Kevin Benton blak...@gmail.com writes:

  What you are proposing sounds very reasonable. If I understand
  correctly, the idea is to make Nova just create the TAP device and get
  it attached to the VM and leave it 'unplugged'. This would work well
  and might eliminate the need for some drivers. I see no reason to
  block adding a VIF type that does this.

 I was actually floating a slightly more radical option than that: the
 idea that there is a VIF type (VIF_TYPE_NOOP) for which Nova does
 absolutely _nothing_, not even create the TAP device.

 (My pending Nova spec at https://review.openstack.org/#/c/130732/
 proposes VIF_TYPE_TAP, for which Nova _does_ creates the TAP device, but
 then does nothing else - i.e. exactly what you've described just above.
 But in this email thread I was musing about going even further, towards
 providing a platform for future networking experimentation where Nova
 isn't involved at all in the networking setup logic.)

  However, there is a good reason that the VIF type for some OVS-based
  deployments require this type of setup. The vSwitches are connected to
  a central controller using openflow (or ovsdb) which configures
  forwarding rules/etc. Therefore they don't have any agents running on
  the compute nodes from the Neutron side to perform the step of getting
  the interface plugged into the vSwitch in the first place. For this
  reason, we will still need both types of VIFs.

 Thanks.  I'm not advocating that existing VIF types should be removed,
 though - rather wondering if similar function could in principle be
 implemented without Nova VIF plugging - or what that would take.

 For example, suppose someone came along and wanted to implement a new
 OVS-like networking infrastructure?  In principle could they do that
 without having to enhance the Nova VIF driver code?  I think at the
 moment they couldn't, but that they would be able to if VIF_TYPE_NOOP
 (or possibly VIF_TYPE_TAP) was already in place.  In principle I think
 it would then be possible for the new implementation to specify
 VIF_TYPE_NOOP to Nova, and to provide a Neutron agent that does the kind
 of configuration and vSwitch plugging that you've described above.

 Does that sound correct, or am I missing something else?

  1 .When the port is created in the Neutron DB, and handled (bound
  etc.)
  by the plugin and/or mechanism driver, the TAP device name is already
  present at that time.
 
  This is backwards. The tap device name is derived from the port ID, so
  the port has already been created in Neutron at that point. It is just
  unbound. The steps are roughly as follows: Nova calls neutron for a
  port, Nova creates/plugs VIF based on port, Nova updates port on
  Neutron, Neutron binds the port and notifies agent/plugin/whatever to
  finish the plumbing, Neutron notifies Nova that port is active, Nova
  unfreezes the VM.
 
  None of that should be affected by what you are proposing. The only
  difference is that your Neutron agent would also perform the
  'plugging' operation.

 Agreed - but thanks for clarifying the exact sequence of events.

 I wonder if what I'm describing (either VIF_TYPE_NOOP or VIF_TYPE_TAP)
 might fit as part of the Nova-network/Neutron Migration priority
 that's just been announced for Kilo.  I'm aware that a part of that
 priority is concerned with live migration, but perhaps it could also
 include the goal of future networking work not having to touch Nova
 code?

 Regards,
 Neil




 --
 Kevin Benton

 ___
 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][neutron] Boundary between Nova and Neutron involvement in network setup?

2014-12-05 Thread Kevin Benton
I see the difference now.
The main concern I see with the NOOP type is that creating the virtual
interface could require different logic for certain hypervisors. In that
case Neutron would now have to know things about nova and to me it seems
like that's slightly too far the other direction.

On Thu, Dec 4, 2014 at 8:00 AM, Neil Jerram neil.jer...@metaswitch.com
wrote:

 Kevin Benton blak...@gmail.com writes:

  What you are proposing sounds very reasonable. If I understand
  correctly, the idea is to make Nova just create the TAP device and get
  it attached to the VM and leave it 'unplugged'. This would work well
  and might eliminate the need for some drivers. I see no reason to
  block adding a VIF type that does this.

 I was actually floating a slightly more radical option than that: the
 idea that there is a VIF type (VIF_TYPE_NOOP) for which Nova does
 absolutely _nothing_, not even create the TAP device.

 (My pending Nova spec at https://review.openstack.org/#/c/130732/
 proposes VIF_TYPE_TAP, for which Nova _does_ creates the TAP device, but
 then does nothing else - i.e. exactly what you've described just above.
 But in this email thread I was musing about going even further, towards
 providing a platform for future networking experimentation where Nova
 isn't involved at all in the networking setup logic.)

  However, there is a good reason that the VIF type for some OVS-based
  deployments require this type of setup. The vSwitches are connected to
  a central controller using openflow (or ovsdb) which configures
  forwarding rules/etc. Therefore they don't have any agents running on
  the compute nodes from the Neutron side to perform the step of getting
  the interface plugged into the vSwitch in the first place. For this
  reason, we will still need both types of VIFs.

 Thanks.  I'm not advocating that existing VIF types should be removed,
 though - rather wondering if similar function could in principle be
 implemented without Nova VIF plugging - or what that would take.

 For example, suppose someone came along and wanted to implement a new
 OVS-like networking infrastructure?  In principle could they do that
 without having to enhance the Nova VIF driver code?  I think at the
 moment they couldn't, but that they would be able to if VIF_TYPE_NOOP
 (or possibly VIF_TYPE_TAP) was already in place.  In principle I think
 it would then be possible for the new implementation to specify
 VIF_TYPE_NOOP to Nova, and to provide a Neutron agent that does the kind
 of configuration and vSwitch plugging that you've described above.

 Does that sound correct, or am I missing something else?

  1 .When the port is created in the Neutron DB, and handled (bound
  etc.)
  by the plugin and/or mechanism driver, the TAP device name is already
  present at that time.
 
  This is backwards. The tap device name is derived from the port ID, so
  the port has already been created in Neutron at that point. It is just
  unbound. The steps are roughly as follows: Nova calls neutron for a
  port, Nova creates/plugs VIF based on port, Nova updates port on
  Neutron, Neutron binds the port and notifies agent/plugin/whatever to
  finish the plumbing, Neutron notifies Nova that port is active, Nova
  unfreezes the VM.
 
  None of that should be affected by what you are proposing. The only
  difference is that your Neutron agent would also perform the
  'plugging' operation.

 Agreed - but thanks for clarifying the exact sequence of events.

 I wonder if what I'm describing (either VIF_TYPE_NOOP or VIF_TYPE_TAP)
 might fit as part of the Nova-network/Neutron Migration priority
 that's just been announced for Kilo.  I'm aware that a part of that
 priority is concerned with live migration, but perhaps it could also
 include the goal of future networking work not having to touch Nova
 code?

 Regards,
 Neil




-- 
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova][neutron] Boundary between Nova and Neutron involvement in network setup?

2014-12-05 Thread Neil Jerram
Ian Wells ijw.ubu...@cack.org.uk writes:

 On 4 December 2014 at 08:00, Neil Jerram neil.jer...@metaswitch.com
 wrote:

 Kevin Benton blak...@gmail.com writes:
 I was actually floating a slightly more radical option than that:
 the
 idea that there is a VIF type (VIF_TYPE_NOOP) for which Nova does
 absolutely _nothing_, not even create the TAP device.
 

 Nova always does something, and that something amounts to 'attaches
 the VM to where it believes the endpoint to be'. Effectively you
 should view the VIF type as the form that's decided on during
 negotiation between Neutron and Nova - Neutron says 'I will do this
 much and you have to take it from there'. (In fact, I would prefer
 that it was *more* of a negotiation, in the sense that the hypervisor
 driver had a say to Neutron of what VIF types it supported and
 preferred, and Neutron could choose from a selection, but I don't
 think it adds much value at the moment and I didn't want to propose a
 change just for the sake of it.) I think you're just proposing that
 the hypervisor driver should do less of the grunt work of connection.

 Also, libvirt is not the only hypervisor driver and I've found it
 interesting to nose through the others for background reading, even if
 you're not using them much.

 For example, suppose someone came along and wanted to implement a
 new
 OVS-like networking infrastructure? In principle could they do
 that
 without having to enhance the Nova VIF driver code? I think at the
 moment they couldn't, but that they would be able to if
 VIF_TYPE_NOOP
 (or possibly VIF_TYPE_TAP) was already in place. In principle I
 think
 it would then be possible for the new implementation to specify
 VIF_TYPE_NOOP to Nova, and to provide a Neutron agent that does
 the kind
 of configuration and vSwitch plugging that you've described above.
 

 At the moment, the rule is that *if* you create a new type of
 infrastructure then *at that point* you create your new VIF plugging
 type to support it - vhostuser being a fine example, having been
 rejected on the grounds that it was, at the end of Juno, speculative.
 I'm not sure I particularly like this approach but that's how things
 are at the moment - largely down to not wanting to add code that isn;t
 used and therefore tested.

 None of this is criticism of your proposal, which sounds reasonable; I
 was just trying to provide a bit of context.

Many thanks for your explanations; I think I'm understanding this more
fully now.  For example, I now see that, when using libvirt, Nova has to
generate config that describes all aspects of the VM to launch,
including how the VNIC is implemented and how it's bound to networking
on the host.  Also different hypervisors, or layers like libvirt, may go
to different lengths as regards how far they connect the VNIC to some
form of networking on the host, and I can see that Nova would want to
normalize that, i.e. to ensure that a predictable level of connectivity
has always been achieved, regardless of hypervisor, by the time that
Nova hands over to someone else such as Neutron.

Therefore I see now that Nova _must_ be involved to some extent in VIF
plugging, and hence that VIF_TYPE_NOOP doesn't fly.

For a minimal, generic implementation of an unbridged TAP interface,
then, we're back to VIF_TYPE_TAP as I've proposed in
https://review.openstack.org/#/c/130732/.  I've just revised and
reuploaded this, based on the insight provided by this ML thread, and
hope people will take a look.

Many thanks,
 Neil


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova][neutron] Boundary between Nova and Neutron involvement in network setup?

2014-12-05 Thread Neil Jerram
Kevin Benton blak...@gmail.com writes:

 I see the difference now. 
 The main concern I see with the NOOP type is that creating the virtual
 interface could require different logic for certain hypervisors. In
 that case Neutron would now have to know things about nova and to me
 it seems like that's slightly too far the other direction. 

Many thanks, Kevin.  I see this now too, as I've just written more fully
in my response to Ian.

Based on your and others' insight, I've revised and reuploaded my
VIF_TYPE_TAP spec, and hope it's a lot clearer now.

Regards,
 Neil

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova][neutron] Boundary between Nova and Neutron involvement in network setup?

2014-12-04 Thread Neil Jerram
Kevin Benton blak...@gmail.com writes:

 What you are proposing sounds very reasonable. If I understand
 correctly, the idea is to make Nova just create the TAP device and get
 it attached to the VM and leave it 'unplugged'. This would work well
 and might eliminate the need for some drivers. I see no reason to
 block adding a VIF type that does this.

I was actually floating a slightly more radical option than that: the
idea that there is a VIF type (VIF_TYPE_NOOP) for which Nova does
absolutely _nothing_, not even create the TAP device.

(My pending Nova spec at https://review.openstack.org/#/c/130732/
proposes VIF_TYPE_TAP, for which Nova _does_ creates the TAP device, but
then does nothing else - i.e. exactly what you've described just above.
But in this email thread I was musing about going even further, towards
providing a platform for future networking experimentation where Nova
isn't involved at all in the networking setup logic.)

 However, there is a good reason that the VIF type for some OVS-based
 deployments require this type of setup. The vSwitches are connected to
 a central controller using openflow (or ovsdb) which configures
 forwarding rules/etc. Therefore they don't have any agents running on
 the compute nodes from the Neutron side to perform the step of getting
 the interface plugged into the vSwitch in the first place. For this
 reason, we will still need both types of VIFs. 

Thanks.  I'm not advocating that existing VIF types should be removed,
though - rather wondering if similar function could in principle be
implemented without Nova VIF plugging - or what that would take.

For example, suppose someone came along and wanted to implement a new
OVS-like networking infrastructure?  In principle could they do that
without having to enhance the Nova VIF driver code?  I think at the
moment they couldn't, but that they would be able to if VIF_TYPE_NOOP
(or possibly VIF_TYPE_TAP) was already in place.  In principle I think
it would then be possible for the new implementation to specify
VIF_TYPE_NOOP to Nova, and to provide a Neutron agent that does the kind
of configuration and vSwitch plugging that you've described above.

Does that sound correct, or am I missing something else?

 1 .When the port is created in the Neutron DB, and handled (bound
 etc.)
 by the plugin and/or mechanism driver, the TAP device name is already
 present at that time.

 This is backwards. The tap device name is derived from the port ID, so
 the port has already been created in Neutron at that point. It is just
 unbound. The steps are roughly as follows: Nova calls neutron for a
 port, Nova creates/plugs VIF based on port, Nova updates port on
 Neutron, Neutron binds the port and notifies agent/plugin/whatever to
 finish the plumbing, Neutron notifies Nova that port is active, Nova
 unfreezes the VM. 

 None of that should be affected by what you are proposing. The only
 difference is that your Neutron agent would also perform the
 'plugging' operation.

Agreed - but thanks for clarifying the exact sequence of events.

I wonder if what I'm describing (either VIF_TYPE_NOOP or VIF_TYPE_TAP)
might fit as part of the Nova-network/Neutron Migration priority
that's just been announced for Kilo.  I'm aware that a part of that
priority is concerned with live migration, but perhaps it could also
include the goal of future networking work not having to touch Nova
code?

Regards,
Neil

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova][neutron] Boundary between Nova and Neutron involvement in network setup?

2014-12-04 Thread Ian Wells
On 4 December 2014 at 08:00, Neil Jerram neil.jer...@metaswitch.com wrote:

 Kevin Benton blak...@gmail.com writes:
 I was actually floating a slightly more radical option than that: the
 idea that there is a VIF type (VIF_TYPE_NOOP) for which Nova does
 absolutely _nothing_, not even create the TAP device.


Nova always does something, and that something amounts to 'attaches the VM
to where it believes the endpoint to be'.  Effectively you should view the
VIF type as the form that's decided on during negotiation between Neutron
and Nova - Neutron says 'I will do this much and you have to take it from
there'.  (In fact, I would prefer that it was *more* of a negotiation, in
the sense that the hypervisor driver had a say to Neutron of what VIF types
it supported and preferred, and Neutron could choose from a selection, but
I don't think it adds much value at the moment and I didn't want to propose
a change just for the sake of it.)  I think you're just proposing that the
hypervisor driver should do less of the grunt work of connection.

Also, libvirt is not the only hypervisor driver and I've found it
interesting to nose through the others for background reading, even if
you're not using them much.

For example, suppose someone came along and wanted to implement a new
 OVS-like networking infrastructure?  In principle could they do that
 without having to enhance the Nova VIF driver code?  I think at the
 moment they couldn't, but that they would be able to if VIF_TYPE_NOOP
 (or possibly VIF_TYPE_TAP) was already in place.  In principle I think
 it would then be possible for the new implementation to specify
 VIF_TYPE_NOOP to Nova, and to provide a Neutron agent that does the kind
 of configuration and vSwitch plugging that you've described above.


At the moment, the rule is that *if* you create a new type of
infrastructure then *at that point* you create your new VIF plugging type
to support it - vhostuser being a fine example, having been rejected on the
grounds that it was, at the end of Juno, speculative.  I'm not sure I
particularly like this approach but that's how things are at the moment -
largely down to not wanting to add code that isn;t used and therefore
tested.

None of this is criticism of your proposal, which sounds reasonable; I was
just trying to provide a bit of context.
-- 
Ian.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova][neutron] Boundary between Nova and Neutron involvement in network setup?

2014-12-03 Thread Kevin Benton
What you are proposing sounds very reasonable. If I understand correctly,
the idea is to make Nova just create the TAP device and get it attached to
the VM and leave it 'unplugged'. This would work well and might eliminate
the need for some drivers. I see no reason to block adding a VIF type that
does this.

However, there is a good reason that the VIF type for some OVS-based
deployments require this type of setup. The vSwitches are connected to a
central controller using openflow (or ovsdb) which configures forwarding
rules/etc. Therefore they don't have any agents running on the compute
nodes from the Neutron side to perform the step of getting the interface
plugged into the vSwitch in the first place. For this reason, we will still
need both types of VIFs.


 1 .When the port is created in the Neutron DB, and handled (bound etc.)
   by the plugin and/or mechanism driver, the TAP device name is already
   present at that time.

This is backwards. The tap device name is derived from the port ID, so the
port has already been created in Neutron at that point. It is just unbound.
The steps are roughly as follows: Nova calls neutron for a port, Nova
creates/plugs VIF based on port, Nova updates port on Neutron, Neutron
binds the port and notifies agent/plugin/whatever to finish the plumbing,
Neutron notifies Nova that port is active, Nova unfreezes the VM.

None of that should be affected by what you are proposing. The only
difference is that your Neutron agent would also perform the 'plugging'
operation.

For your second point, scanning the integration bridge for new ports is
currently used now, but that's an implementation detail of the reference
OVS driver. It doesn't block your work directly since OVS wouldn't use your
NOOP VIF type anyway.


Cheers,
Kevin Benton

On Wed, Dec 3, 2014 at 8:08 AM, Neil Jerram neil.jer...@metaswitch.com
wrote:

 Hi there.  I've been looking into a tricky point, and hope I can succeed
 in expressing it clearly here...

 I believe it is the case, even when using a committedly Neutron-based
 networking implementation, that Nova is still involved a little bit in
 the networking setup logic.  Specifically I mean the plug() and unplug()
 operations, whose implementations are provided by *VIFDriver classes for
 the various possible hypervisors.

 For example, for the libvirt hypervisor, LibvirtGenericVIFDriver
 typically implements plug() by calling create_tap_dev() to create the
 TAP device, and then plugging into some form of L2 bridge.

 Does this logic actually have to be in Nova?  For a Neutron-based
 networking implementation, it seems to me that it should also be
 possible to do this in a Neutron agent (obviously running on the compute
 node concerned), and that - if so - that would be preferable because it
 would enable more Neutron-based experimentation without having to modify
 any Nova code.

 Specifically, therefore, I wonder if we could/should add a do-nothing
 value to the set of Nova VIF types (VIF_TYPE_NOOP?), and implement
 plug()/unplug() for that value to do nothing at all, leaving all setup
 to the Neutron agent?  And then hopefully it should never be necessary
 to introduce further Nova VIF type support ever again...

 Am I missing something that really makes that not fly?  Two possible
 objections occurs to me, as follows, but I think they're both
 surmountable.

 1. When the port is created in the Neutron DB, and handled (bound etc.)
by the plugin and/or mechanism driver, the TAP device name is already
present at that time.

I think this is still OK because Neutron knows anyway what the TAP
device name _will_ be, even if the actual TAP device hasn't been
created yet.

 2. With some agent implementations, there isn't a direct instruction,
from the plugin to the agent, to say now look after this VM /
port.  Instead the agents polls the OS for new TAP devices
appearing.  Clearly, then, if there isn't something other than the
agent that creates the TAP device, any logic in the agent will never
be triggered.

This is certain a problem.  For new networking experimentation,
however, we can write agent code that is directly instructed by the
plugin, and hence (a) doesn't need to poll (b) doesn't require the
TAP device to have been previously created by Nova - which I'd argue
is preferable.

 Thoughts?

 (FYI my context is that I've been working on a networking implementation
 where the TAP device to/from a VM should _not_ be plugged into a bridge
 - and for that I've had to make a Nova change even though my team's aim
 was to do the whole thing in Neutron.

 I've proposed a spec for the Nova change that plugs a TAP interface
 without bridging it (https://review.openstack.org/#/c/130732/), but that
 set me wondering about this wider question of whether such Nova changes
 should still be necessary...)

 Many thanks,
  Neil

 ___
 OpenStack-dev mailing list