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