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