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).
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).
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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
