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.
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : [email protected]
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
