Open Stack

On Fri, Dec 12, 2014 at 3:16 PM, Daniel P. Berrange <berrange at 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
>> <berrange at 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 <berrange at 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