On Tue, Feb 24, 2015 at 3:30 AM, Laine Stump <laine@redhat.com> wrote:
We actively avoid calling free-form scripts as much as possible. It isOn 02/23/2015 08:48 PM, YAMAMOTO Takashi wrote:
>> On Tue, Feb 24, 2015 at 2:20 AM, YAMAMOTO Takashi <yamamoto@valinux.co.jp>
>> wrote:
>>
>>>> Adds the port type definitions and methods that will be used to bind
>>>> interfaces to the Midonet virtual ports.
>>>>
>>>> virtnetdevmidonet.c adds the way to bind and unbind the ports by
>>>> calling into the Midonet Host Agent control command line (installed
>>>> with the midolman package).
>>>>
>>>> Signed-off-by: Antoni Segura Puimedon <toni+libvirt@midokura.com>
>>>
>>> have you considered a script-based solution which would be able
>>> to cover openvswitch case as well?
>>>
>>
>> Can you elaborate? For script I can only think about having an xml node
>> that can be specified for the port type that says what should be run for
>> attachment (like with the ethernet mode). But I'm not sure how it would fit
>> right now.
>
> i meant to have a "run a script" port type.
> the script runs ovs-vsctl, mm-ctl, or whatever internally.
too difficult to support, and opens the possibility of security problems.
For that matter, we even prefer to not call external binaries if we can
avoid it, and eliminate existing executions of external binaries
whenever we get the change. The only reason we agreed to executing
ovs-vsctl is because there is no defined public API for Open vSwitch
that uses a library, netlink message, ioctl, etc. (at least there wasn't
at the time that code was added).
I was wondering for some time if it would make it better for ovs and
midonet, in terms of interoperability with the rest of the linux stack
(in this case libvirt) if they exposed their methods to dbus. What do
you think about that? (obviously that would take a few releases of
both.