Open Stack

>
> 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