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 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
