[libvirt] [PATCH 1/3 v3] utilities for supporting midonet virtualports

Laine Stump laine at laine.org
Tue Mar 17 15:26:19 UTC 2015


On 02/24/2015 04:17 AM, Antoni Segura Puimedon wrote:
>
>
> On Tue, Feb 24, 2015 at 3:30 AM, Laine Stump <laine at redhat.com
> <mailto:laine at redhat.com>> wrote:
>
>     On 02/23/2015 08:48 PM, YAMAMOTO Takashi wrote:
>     >> On Tue, Feb 24, 2015 at 2:20 AM, YAMAMOTO Takashi
>     <yamamoto at valinux.co.jp <mailto:yamamoto at 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 at midokura.com <mailto:toni%2Blibvirt at 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.
>
>     We actively avoid calling free-form scripts as much as possible. It is
>     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.
>

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20150317/00c16244/attachment-0001.htm>


More information about the libvir-list mailing list