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

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.

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

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

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

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

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

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

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