Open Stack

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.hirofumi at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev