openstack team mailing list archive

[Adam Young <ayoung@xxxxxxxxxx>]

On 07/30/2012 05:12 AM, Thierry Carrez wrote:
> Lorin Hochstein wrote:
> > I wanted to discuss the usability of the paste config files from an
> > operator's point of view. The paste config files are opaque to
> > administrators who are trying to stand an OpenStack cloud for the first
> > time, since they expose a lot of implementation details about the
> > middleware. I can follow the instructions in the Install and Deploy
> > guide, but I have no idea what the options I don't edit are, and if the
> > documentation has deviated from the implementation, I'm pretty much stuck.
> > [...]
> This was mentioned in the "Making configuration easier" session on the
> DevOps track at the last design summit. You can find the notes at:
>
> http://etherpad.openstack.org/FolsomMakingConfigurationEasier
>
> In particular, it was identified that paste configs were evil, failing
> to properly separate service/code configuration from end-user configuration.
>
> > Assuming that the *-paste.ini files always need to be there, is there some way we could avoid requiring admins to edit these files, and instead make it more like editing the .conf files? For example, could the paste.ini files be generated from the corresponding .conf file as needed?
> I would not assume that *-paste.ini files always need to be there...
> Paste is a pain point if we are to support Python 3 one day, so it's
> also on the black list of the (still inexistant) OpenStack Python3
> advocacy group.
>
> So I'd rather investigate a solution that solves our two problems,
> rather than adding a layer on top of the current broken solution... That
> said I'm not really a specialist of Paste alternatives.
It seems to me that there is nothing that you can do in Paste that you 
cannot do in straight python.  THe advantage of Paste is hat it is 
viewed as a Config file, not as "code" and thus is a file that end 
system administrators can use.


A paste file is nothing more than an assignment to a variable name from 
a string that is  done at run time.  For example,   the Keystone config 
file has a paste fragment in it:

[app:public_version_service]
paste.app_factory = keystone.service:public_version_app_factory



This same code could be performed inside the Python code base with 
pretty much the same code interpred as Python.  The issue is that we 
would then want to allow a value such as this to be overridden:

For example, specifying the driver for the token api is done:

[token]
 driver = keystone.token.backends.kvs.Token

Since most of these cases have reasonable defaults,  they should be left 
out of the paste files.  What needs to be available is solid 
documentation of the values that can be overridden this way.  Any keys 
that are not defaulted,  but are not really designed to be overloaded 
should be modified so that they are defaulted, and then the keys removed 
from the paste file.