[ovs-dev] OVN configuration

[Ben Pfaff]

On Mon, Jul 20, 2015 at 11:18:56AM -0700, Ben Pfaff wrote:
> On Mon, Jul 20, 2015 at 02:06:26PM -0400, Russell Bryant wrote:
> > On 07/20/2015 01:46 PM, Ben Pfaff wrote:
> > >>>> Regarding this patch, to be honest, the choice of "bridge mappings" is
> > >>>> just borrowed from the existing OVS support in OpenStack.  What's
> > >>>> implemented here matches how that works.  It expects the bridge to be
> > >>>> created already, but automatically creates patch ports to/from the
> > >>>> integration bridge.  I don't feel experienced enough with OVS to really
> > >>>> feel confident in suggesting the proper balance between "just works" and
> > >>>> "useful flexibility".
> > >>>
> > >>> I didn't know there was precedent here.  How is the configuration
> > >>> conveyed to that existing plugin?  I mean, where does it get the
> > >>> configuration from (presumably it's not from the same external-ids key
> > >>> but if it is then so much the better).
> > >>>
> > >>> Looking at an installation manual, it looks like it's configured through
> > >>> essentially an old-school Windows INI file with a .conf extension.  I
> > >>> don't know whether that's better or worse than the OVS DB.
> > >>
> > >> Yes, it's in an ini conf file.  Similar style conf files are used for
> > >> all OpenStack services.
> > >>
> > >> I actually think a conf file would be easier than ovsdb for
> > >> ovn-controller config.  That seems easier to manage from config
> > >> management tools (puppet, chef, ...).
> > > 
> > > OVS once used an ini-like config file instead of OVSDB.  It worked fine
> > > as long as configuration was really simple.  As we added more features,
> > > drawbacks started taking larger tolls: it's difficult to update a
> > > configuration file remotely or transactionally, and it's hard to monitor
> > > a configuration file for fast updates.  (OVSDB has another advantage
> > > that wasn't obvious until we started using it: when something goes
> > > wrong, you can review the log to figure out who screwed up.)
> > > 
> > > These are key properties in my opinion.  If the information in question
> > > is mostly statically configured and centrally managed (i.e. there's no
> > > need to worry about two different parties making conflicting changes),
> > > and it's acceptable to restart ovn-controller if any of it changes, then
> > > a simple configuration mechanism like an INI file or command-line
> > > options seems appropriate to me.
> > > 
> > > I think that the OVN-specific configuration data we have so far, plus
> > > the data proposed for patch ports, fits that description.
> > > 
> > > I guess the question, then, is what advantages the INI format offers.  I
> > > guess that a transparent text format is nice, and it sounds like there
> > > are widely used configuration management tools for distributing changes.
> > > Maybe that's enough.
> > > 
> > 
> > On the flip side, people have probably figured out how to manage OVS
> > itself just fine through those same config management tools, so maybe
> > it's not that big of a deal.  A quick google certainly produces plenty
> > of results about puppet and ovs, for example.
> > 
> > I'd really love to get some feedback from those with more ops experience
> > on this.  I want to do whatever works and makes their lives easiest.
> 
> Ditto!

It sounds like your discussions with people in this area indicate that
configuration files are preferred.  Also Kevin in #openvswitch said the
same thing.