Oh right, I'm definitely for eliminating these values from Devstack and just telling people to use post-config. I was just hesitant about advocating for their removal from neutron.
On Mon, Apr 11, 2016 at 3:55 PM, Brandon Logan <brandon.lo...@rackspace.com> wrote: > On Mon, 2016-04-11 at 15:30 -0700, Kevin Benton wrote: > > >[1]: > https://github.com/openstack-dev/devstack/blob/master/lib/neutron-legacy#L178 > > >[2]: > https://github.com/openstack/nova/blob/master/nova/conf/virt.py#L164-L166 > > > > > > This is a Nova option to decide how long to wait for Neutron to > > callback before considering a port failed to be wired. The time this > > will take will depend quite a bit on how heavily loaded the system is. > > We can certainly try to get rid of it, but it means that we have to > > force assumptions about how quickly a system should give up waiting > > for wiring. It would be similar to getting rid of the option to choose > > a timeout value for the API clients. > > > > > > > > >[3]: > https://github.com/openstack-dev/devstack/blob/master/lib/neutron-legacy#L162 > > >[4]: > https://github.com/openstack/neutron/blob/master/neutron/common/config.py#L53 > > > > > > Neutron does not need to be deployed with keystone. This is how you > > disable it. Some operators do not have Neutron exposed to tenants so > > keystone is stripped away for performance since the only things > > communicating with Neutron are internal trusted services. > > This is correct. In a large deployment the number of requests going to > keystone dramatically affects performance. Do you think this needs to > be a devstack config option though? I kind of don't think it does for > no better reason than it's easy to just change the option in the > neutron.conf and restart. > > > > > On Mon, Apr 11, 2016 at 12:42 PM, Hirofumi Ichihara > > <ichihara.hirof...@lab.ntt.co.jp> wrote: > > I agree. Throughout I was reviewing Devstack over 3 cycles, > > I thought the same thing. Devstack often accepted patches just > > adding option although we're not sure who really needs the > > options. > > There are many useless stuff in the options. > > For example, default value of devstack option is the same > > value as > > default in Projects. Please look at [1] and [2], [3] and [4]. > > Who uses these options? > > > > We can see such options in devstack throughout. I agree we > > will adjust default configurations and > > that documents in Neutron side. However, let's eliminate such > > options are clearly useless first. > > And then we should do after we made necessary options clear. > > > > [1]: > > > https://github.com/openstack-dev/devstack/blob/master/lib/neutron-legacy#L178 > > [2]: > > > https://github.com/openstack/nova/blob/master/nova/conf/virt.py#L164-L166 > > [3]: > > > https://github.com/openstack-dev/devstack/blob/master/lib/neutron-legacy#L162 > > [4]: > > > https://github.com/openstack/neutron/blob/master/neutron/common/config.py#L53 > > > > Thanks, > > Hirofumi > > > > > > On 2016/04/09 0:07, Sean M. Collins 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 > > > > > > > > > > > > > > > __________________________________________________________________________ > > 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 > > __________________________________________________________________________ > 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