Re: [Openstack] Hiding complexity of paste config files from operators
On Jul 30, 2012, at 9:48 AM, Adam Young ayo...@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 smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Hiding complexity of paste config files from operators
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. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Hiding complexity of paste config files from operators
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 : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Hiding complexity of paste config files from operators
All: 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. As an example, the install and deploy guide says to add authtoken to the pipeline:glance-api section in glance-api-paste.ini http://docs.openstack.org/essex/openstack-compute/install/content/configure-glance-files.html, the example in the docs looks like this: [pipeline:glance-api] pipeline = versionnegotiation authtoken auth-context apiv1app If I install from packages on precise, there's also some lines that look like this: [pipeline:glance-api-keystone] pipeline = versionnegotiation authtoken context apiv1app It looks similar, and it has keystone in there, so maybe that's intended to be used for keystone? And it looks pretty similar, but there's a auth-context instead of context. Maybe the pipeline:glance-api-keystone is used for something else in glance? In the end, I'm just going to slavishly follow the documentation, and I have no mental model of what these options do. On the other hand, the traditional configuration files (e.g., nova.conf) are (relatively) well-documented, have default values, and everything that's exposed is something that could potentially be changed by an administrator. In particular, there's generally a one-to-one correspondence between changing a configuration setting and changing the behavior of the system in a way that's meaningful for the operator. For example, enabling FlatDHCP in nova.conf is just setting a config option to one value: network_manager=nova.network.manager.FlatDHCPManager 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? Take care, Lorin -- Lorin Hochstein Lead Architect - Cloud Services Nimbis Services, Inc. www.nimbisservices.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
