Open Stack

This is a very solid plan. Maybe to fair on the current state of the devstack with neutron functionality, what will be the disadvantage(s) of this change from your perspective?

Edgar



On 4/8/16, 8:07 AM, "Sean M. Collins" <sean at 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-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev