Open Stack

On Jul 30, 2012, at 9:48 AM, Adam Young <ayoung at redhat.com> 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




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120801/e90fba99/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4897 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120801/e90fba99/attachment.bin>