Open Stack

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 <henry4hly at 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 <blak111 at 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.Jerram at metaswitch.com>
> > wrote:
> >>
> >> Kevin Benton <blak111 at 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 at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141210/25c5613c/attachment.html>