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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
