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

Laine Stump <laine@xxxxxxxxx> · Tue, 17 Mar 2015 11:26:19 -0400



    On 02/24/2015 04:17 AM, Antoni Segura
      Puimedon wrote:

    
          On Tue, Feb 24, 2015 at 3:30 AM,
            Laine Stump <laine@xxxxxxxxxx>
            wrote:

            
                On 02/23/2015 08:48 PM, YAMAMOTO Takashi
                  wrote:

                  >> On Tue, Feb 24, 2015 at 2:20 AM, YAMAMOTO
                  Takashi <yamamoto@xxxxxxxxxxxxx>

                  >> 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@xxxxxxxxxxxx>

                  >>>

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

  
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list