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
