Agree, sometimes is hard to figure out what is the Devstack variable that will modify the configuration value.
There is an effort to categorize the configuration options[1] of some of the projects. I’m wondering if it could be possible to create category or field that specifies the Destack variable that changes this configuration value. [1] https://review.openstack.org/#/c/295543/8/specs/categorized-configuration-options.rst Victor Morales On 4/8/16, 10:07 AM, "Sean M. Collins" <s...@coreitpro.com> wrote: >Prior to the introduction of local.conf, the only way to configure >OpenStack components was to introduce code directly into DevStack, so >that DevStack would pick it up then inject it into the configuration >file. > >This was because DevStack writes out new configuration files on each >run, so it wasn't possible for you to make changes to any configuration >file (nova.conf, neutron.conf, ml2_plugin.ini, etc..). > >So, someone who wanted to set the Linux Bridge Agent's >physical_interface_mappings setting for Neutron would have to use >$LB_INTERFACE_MAPPINGS in DevStack, which would then be invoked by >DevStack[1]. > >The local.conf functionality was introduced quite a while back, and >I think it's time to have a conversation about why we should start >moving away from the previous practice of declaring variables in >DevStack, and then having them injected into the configuration files. > >The biggest issue is: There is a disconnect between the developers >using DevStack and someone who is an operator or who has been editing >OpenStack conf files directly. So, for example I can tell you all about >how DevStack has a bunch of variables for configuring Neutron (which is >Not a Good Thing™), and how those go into DevStack and then end up coming >out the other side in a Neutron configuration file. > >Really, I would like to get rid of the intermediate layer (DevStack) >and get both Devs and Deployers to be able to just say: Here's my >neutron.conf - let's diff mine and yours and see what we need to sync. > >Matt Kassawara and I have had this issue, since he's coming from the >OSAD side, and I'm coming from the DevStack side. We both know what the >Neutron configuration should end up as, but DevStack having its own set >of variables and how those variables are handled and eventually rendered >as a Neutron config file makes things more difficult than it needs to >be, since Matt has to now go and learn about how DevStack handles all >these Neutron specific variables. > >The Neutron refactor[2] that I am working on, I am trying to configure >as little as possible in DevStack. Neutron should be able to, out of the >box, Just Work™. If it can't, then that needs to be fixed in Neutron. > >Secondly, the Neutron refactor will be getting rid of all the things >like $LB_INTERFACE_MAPPINGS - I would *much* prefer that someone using >DevStack actually set the apropriate line in their local.conf > >Such as: > > [[post-config|/$Q_PLUGIN_CONF_FILE]] > [linux_bridge] > physical_interface_mappings = foo:bar > > >The advantage of this is, when someone is working with DevStack, the >things they are configuring are the same as all the other OpenStack >documentation. > >For example, someone could read the Networking Guide, read the example >configuration[3] and the only thing they'd need to learn is our syntax >for specifying what file the contents go in (the >"[[post-config|/$Q_PLUGIN_CONF_FILE]]" piece). > >Thoughts? > >[1]: >https://github.com/openstack-dev/devstack/blob/1195a5b7394fc5b7a1cb1415978e9997701f5af1/lib/neutron_plugins/linuxbridge_agent#L63 > >[2]: https://review.openstack.org/168438 > >[3]: >http://docs.openstack.org/liberty/networking-guide/scenario-classic-lb.html#example-configuration > >-- >Sean M. Collins > >__________________________________________________________________________ >OpenStack Development Mailing List (not for usage questions) >Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev