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.lo...@rackspace.com <mailto: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
<mailto: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://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://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://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
