Open Stack

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
>