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

Antoni Segura Puimedon toni at midokura.com
Tue Mar 17 16:15:29 UTC 2015


On Tue, Mar 17, 2015 at 4:26 PM, Laine Stump <laine at laine.org> wrote:

>  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> 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>
>> >> 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>
>> >>>
>> >>> 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.
>

I'll check it out for a future binding. We'll still have the cli, but maybe
we can update this to use some netlink/protobuf/dbus api call.


>
> 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.
>

Indeed!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20150317/2069f68f/attachment-0001.htm>


More information about the libvir-list mailing list