Just now saw this message. It would be really nice if they exposed their methods *somehow* (I'm curious why you suggest dbus; what about netlink? I have no love for netlink (or dbus), but other network things (aside from NetworkManager) seem to use netlink.On 02/24/2015 04:17 AM, Antoni Segura Puimedon wrote:
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.
The really important thing, though, is that whatever API is provided, that it be *set in stone* and never change in a way that isn't backward compatible. libvirt's API is an example of doing this successfully - years have gone by and we haven't had to increment the .so major version.