[openstack-dev] [devstack][neutron] Eliminating the DevStack layer
Hirofumi Ichihara
ichihara.hirofumi at lab.ntt.co.jp
Tue Apr 12 02:57:48 UTC 2016
On 2016/04/12 8:02, Kevin Benton wrote:
> 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.
Yeah, my point is eliminating useless options from Devstack since we can
change them in post-config of local.conf if need.
>
> On Mon, Apr 11, 2016 at 3:55 PM, Brandon Logan
> <brandon.logan at rackspace.com <mailto: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
> <mailto: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://OpenStack-dev-request@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://OpenStack-dev-request@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://OpenStack-dev-request@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/20160412/11eb6f3f/attachment.html>
More information about the OpenStack-dev
mailing list