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