On Fri, Dec 12, 2014 at 3:16 PM, Daniel P. Berrange <berra...@redhat.com> wrote: > On Fri, Dec 12, 2014 at 03:05:28PM +0100, Maxime Leroy wrote: >> On Fri, Dec 12, 2014 at 10:46 AM, Daniel P. Berrange >> <berra...@redhat.com> wrote: >> > On Fri, Dec 12, 2014 at 01:21:36PM +0900, Ryu Ishimoto wrote: >> >> On Thu, Dec 11, 2014 at 7:41 PM, Daniel P. Berrange <berra...@redhat.com> >> >> wrote: >> >> >> [..] >> >> Port binding mechanism could vary among different networking technologies, >> >> which is not nova's concern, so this proposal makes sense. Note that some >> >> vendors already provide port binding scripts that are currently executed >> >> directly from nova's vif.py ('mm-ctl' of midonet and 'ifc_ctl' for iovisor >> >> are two such examples), and this proposal makes it unnecessary to have >> >> these hard-coded in nova. The only question I have is, how would nova >> >> figure out the arguments for these scripts? Should nova dictate what they >> >> are? >> > >> > We could define some standard set of arguments & environment variables >> > to pass the information from the VIF to the script in a standard way. >> > >> >> Many information are used by the plug/unplug method: vif_id, >> vif_address, ovs_interfaceid, firewall, net_id, tenant_id, vnic_type, >> instance_uuid... >> >> Not sure we can define a set of standard arguments. > > That's really not a problem. There will be some set of common info > needed for all. Then for any particular vif type we know what extra > specific fields are define in the port binding metadata. We'll just > set env variables for each of those. > >> Maybe instead to use a script we should load some plug/unplug >> functions from a python module with importlib. So a vif_plug_module >> option instead to have a vif_plug_script ? > > No, we explicitly do *not* want any usage of the Nova python modules. > That is all private internal Nova implementation detail that nothing > is permitted to rely on - this is why the VIF plugin feature was > removed in the first place. > >> There are several other problems to solve if we are going to use this >> vif_plug_script: >> >> - How to have the authorization to run this script (i.e. rootwrap)? > > Yes, rootwrap. > >> - How to test plug/unplug function from these scripts? >> Now, we have unity tests in nova/tests/unit/virt/libvirt/test_vif.py >> for plug/unplug method. > > Integration and/or functional tests run for the VIF impl would > exercise this code still. > >> - How this script will be installed? >> -> should it be including in the L2 agent package? Some L2 switch >> doesn't have a L2 agent. > > That's just a normal downstream packaging task which is easily > handled by people doing that work. If there's no L2 agent package > they can trivially just create a new package for the script(s) > that need installing on the comput node. They would have to be > doing exactly this anyway if you had the VIF plugin as a python > module instead. >
Ok, thank you for the details. I will look how to implement this feature. Regards, Maxime _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev