Excerpts from Joshua Harlow's message of 2016-11-07 15:53:51 -0800: > > > > Concretely - oslo.config is important because it shapes what the config > > files look like. The implementation language of a particular service > > shouldn't change what our config files look like, yeah? > > Standards though exist for a reason (and ini files are pretty common > across languages and such); though of course oslo.config has some very > tight integration with openstack, the underlying ini concept it > eventually reads/writes really isn't that special (so hopefully such a > thing existing isn't that hard). > > As a note gflags in go (which I think is the default option mechanism?) > is alot like oslo.config (in fact oslo.config came from a python version > of gflags way back when). > > Personally though I'd prefer to just say (if I could) 'ini' file is the > standard format for options in openstack (and drop the mix of command > line options and configuration/ini file options).
Yes, I wish we hadn't invented our own parser, too. That being said, we did. > > > > > Similarly keystoneauth - not because getting a token from keystone with > > a username and password is necessarily hard- but because we're trying to > > drive more service-service interactions through the catalog to reduce > > the number of things an operator needs to configure directly - and also > > because keystone has auth plugins that need to be supported in the new > > language too. (it's a common fault in non-python client implementations > > that non-password auth plugins are not covered at all) > > > > oslo.log has similar needs - the logging for an operator needs to be > > able to be routed to the same places and be in the same format as the > > existing things. > > Pretty sure most systems have logging that is similar to java logging > (which afaik is where the python logging system came from/was inspired > from); oslo.log has some specific tie-ins to oslo.config (but see above > statement of using a ini file as the option mechanism). Which is good from a developer perspective. From a deployer perspective, the behavior embedded in oslo.log and controlled by the config options is what we would want to reproduce, on top of a native logging system if possible. > > > > > oslo.messaging and oslo.db have needs where they intersect with operator > > config. > > I hope we aren't restricting ourselves to much because of the > specialized libraries we have made that typically have (some level) of > equivalent in other languages. Though of course those languages and > libraries do not typically(?) have the tie-together that we have created > with our libraries (for better or worse). > > -Josh > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
