On Jul 30, 2012, at 9:48 AM, Adam Young <[email protected]> wrote: > 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. >
I logged a doc bug: https://answers.launchpad.net/openstack-manuals/+question/204782 but we really need someone who understands these files to help us document this. Take care, Lorin -- Lorin Hochstein Lead Architect - Cloud Services Nimbis Services, Inc. www.nimbisservices.com
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
