On Tue, Mar 17, 2015 at 4:26 PM, Laine Stump <[email protected]> wrote:
> On 02/24/2015 04:17 AM, Antoni Segura Puimedon wrote: > > > > On Tue, Feb 24, 2015 at 3:30 AM, Laine Stump <[email protected]> wrote: > >> On 02/23/2015 08:48 PM, YAMAMOTO Takashi wrote: >> >> On Tue, Feb 24, 2015 at 2:20 AM, YAMAMOTO Takashi < >> [email protected]> >> >> 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 <[email protected]> >> >>> >> >>> 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!
-- libvir-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/libvir-list
