On Thu, Dec 11, 2014 at 12:36 AM, Kevin Benton 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.
___
OpenSt
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 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
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 w
AP.
>
> Best Regards
> Wu
>
> From: Neil Jerram [neil.jer...@metaswitch.com]
> Sent: Saturday, December 06, 2014 10:51 AM
> To: Kevin Benton
> Cc: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [open
l.jer...@metaswitch.com]
Sent: Saturday, December 06, 2014 10:51 AM
To: Kevin Benton
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][neutron] Boundary between Nova and Neutron
involvement in network setup?
Kevin Benton writes:
> I see the differ
Kevin Benton 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 t
Ian Wells writes:
> On 4 December 2014 at 08:00, Neil Jerram
> wrote:
>
> Kevin Benton 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 creat
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 Th
On 4 December 2014 at 08:00, Neil Jerram wrote:
> Kevin Benton 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
Kevin Benton 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
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
d
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 th
12 matches
Mail list logo
