Open Stack

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.logan at 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.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
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160411/0f34128f/attachment.html>