<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 2016/04/12 8:02, Kevin Benton wrote:<br>
</div>
<blockquote
cite="mid:CAO_F6JMB-1xKGSNapRHnNeDBcsh1TyhN=26Oiaeuz2n1QgwJCg@mail.gmail.com"
type="cite">
<div dir="ltr">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.</div>
</blockquote>
Yeah, my point is eliminating useless options from Devstack since we
can change them in post-config of local.conf if need.<br>
<br>
<br>
<blockquote
cite="mid:CAO_F6JMB-1xKGSNapRHnNeDBcsh1TyhN=26Oiaeuz2n1QgwJCg@mail.gmail.com"
type="cite">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Apr 11, 2016 at 3:55 PM,
Brandon Logan <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:brandon.logan@rackspace.com" target="_blank">brandon.logan@rackspace.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class="">On Mon, 2016-04-11 at 15:30 -0700, Kevin Benton
wrote:<br>
> >[1]: <a moz-do-not-send="true"
href="https://github.com/openstack-dev/devstack/blob/master/lib/neutron-legacy#L178"
rel="noreferrer" target="_blank">https://github.com/openstack-dev/devstack/blob/master/lib/neutron-legacy#L178</a><br>
> >[2]: <a moz-do-not-send="true"
href="https://github.com/openstack/nova/blob/master/nova/conf/virt.py#L164-L166"
rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/master/nova/conf/virt.py#L164-L166</a><br>
><br>
><br>
> This is a Nova option to decide how long to wait for
Neutron to<br>
> callback before considering a port failed to be
wired. The time this<br>
> will take will depend quite a bit on how heavily
loaded the system is.<br>
> We can certainly try to get rid of it, but it means
that we have to<br>
> force assumptions about how quickly a system should
give up waiting<br>
> for wiring. It would be similar to getting rid of the
option to choose<br>
> a timeout value for the API clients.<br>
><br>
><br>
><br>
> >[3]: <a moz-do-not-send="true"
href="https://github.com/openstack-dev/devstack/blob/master/lib/neutron-legacy#L162"
rel="noreferrer" target="_blank">https://github.com/openstack-dev/devstack/blob/master/lib/neutron-legacy#L162</a><br>
> >[4]: <a moz-do-not-send="true"
href="https://github.com/openstack/neutron/blob/master/neutron/common/config.py#L53"
rel="noreferrer" target="_blank">https://github.com/openstack/neutron/blob/master/neutron/common/config.py#L53</a><br>
><br>
><br>
> Neutron does not need to be deployed with keystone.
This is how you<br>
> disable it. Some operators do not have Neutron
exposed to tenants so<br>
> keystone is stripped away for performance since the
only things<br>
> communicating with Neutron are internal trusted
services.<br>
<br>
</span>This is correct. In a large deployment the number of
requests going to<br>
keystone dramatically affects performance. Do you think
this needs to<br>
be a devstack config option though? I kind of don't think
it does for<br>
no better reason than it's easy to just change the option in
the<br>
neutron.conf and restart.<br>
<div class="HOEnZb">
<div class="h5"><br>
><br>
> On Mon, Apr 11, 2016 at 12:42 PM, Hirofumi Ichihara<br>
> <<a moz-do-not-send="true"
href="mailto:ichihara.hirofumi@lab.ntt.co.jp">ichihara.hirofumi@lab.ntt.co.jp</a>>
wrote:<br>
> I agree. Throughout I was reviewing
Devstack over 3 cycles,<br>
> I thought the same thing. Devstack often
accepted patches just<br>
> adding option although we're not sure who
really needs the<br>
> options.<br>
> There are many useless stuff in the
options.<br>
> For example, default value of devstack
option is the same<br>
> value as<br>
> default in Projects. Please look at [1] and
[2], [3] and [4].<br>
> Who uses these options?<br>
><br>
> We can see such options in devstack
throughout. I agree we<br>
> will adjust default configurations and<br>
> that documents in Neutron side. However,
let's eliminate such<br>
> options are clearly useless first.<br>
> And then we should do after we made
necessary options clear.<br>
><br>
> [1]:<br>
> <a moz-do-not-send="true"
href="https://github.com/openstack-dev/devstack/blob/master/lib/neutron-legacy#L178"
rel="noreferrer" target="_blank">https://github.com/openstack-dev/devstack/blob/master/lib/neutron-legacy#L178</a><br>
> [2]:<br>
> <a moz-do-not-send="true"
href="https://github.com/openstack/nova/blob/master/nova/conf/virt.py#L164-L166"
rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/master/nova/conf/virt.py#L164-L166</a><br>
> [3]:<br>
> <a moz-do-not-send="true"
href="https://github.com/openstack-dev/devstack/blob/master/lib/neutron-legacy#L162"
rel="noreferrer" target="_blank">https://github.com/openstack-dev/devstack/blob/master/lib/neutron-legacy#L162</a><br>
> [4]:<br>
> <a moz-do-not-send="true"
href="https://github.com/openstack/neutron/blob/master/neutron/common/config.py#L53"
rel="noreferrer" target="_blank">https://github.com/openstack/neutron/blob/master/neutron/common/config.py#L53</a><br>
><br>
> Thanks,<br>
> Hirofumi<br>
><br>
><br>
> On 2016/04/09 0:07, Sean M. Collins wrote:<br>
> Prior to the introduction of
local.conf, the only way<br>
> to configure<br>
> OpenStack components was to
introduce code directly<br>
> into DevStack, so<br>
> that DevStack would pick it up then
inject it into the<br>
> configuration<br>
> file.<br>
><br>
> This was because DevStack writes
out new configuration<br>
> files on each<br>
> run, so it wasn't possible for you
to make changes to<br>
> any configuration<br>
> file (nova.conf, neutron.conf,
ml2_plugin.ini, etc..).<br>
><br>
> So, someone who wanted to set the
Linux Bridge Agent's<br>
> physical_interface_mappings setting
for Neutron would<br>
> have to use<br>
> $LB_INTERFACE_MAPPINGS in DevStack,
which would then<br>
> be invoked by<br>
> DevStack[1].<br>
><br>
> The local.conf functionality was
introduced quite a<br>
> while back, and<br>
> I think it's time to have a
conversation about why we<br>
> should start<br>
> moving away from the previous
practice of declaring<br>
> variables in<br>
> DevStack, and then having them
injected into the<br>
> configuration files.<br>
><br>
> The biggest issue is: There is a
disconnect between<br>
> the developers<br>
> using DevStack and someone who is
an operator or who<br>
> has been editing<br>
> OpenStack conf files directly. So,
for example I can<br>
> tell you all about<br>
> how DevStack has a bunch of
variables for configuring<br>
> Neutron (which is<br>
> Not a Good Thing™), and how those
go into DevStack and<br>
> then end up coming<br>
> out the other side in a Neutron
configuration file.<br>
><br>
> Really, I would like to get rid of
the intermediate<br>
> layer (DevStack)<br>
> and get both Devs and Deployers to
be able to just<br>
> say: Here's my<br>
> neutron.conf - let's diff mine and
yours and see what<br>
> we need to sync.<br>
><br>
> Matt Kassawara and I have had this
issue, since he's<br>
> coming from the<br>
> OSAD side, and I'm coming from the
DevStack side. We<br>
> both know what the<br>
> Neutron configuration should end up
as, but DevStack<br>
> having its own set<br>
> of variables and how those
variables are handled and<br>
> eventually rendered<br>
> as a Neutron config file makes
things more difficult<br>
> than it needs to<br>
> be, since Matt has to now go and
learn about how<br>
> DevStack handles all<br>
> these Neutron specific variables.<br>
><br>
> The Neutron refactor[2] that I am
working on, I am<br>
> trying to configure<br>
> as little as possible in DevStack.
Neutron should be<br>
> able to, out of the<br>
> box, Just Work™. If it can't, then
that needs to be<br>
> fixed in Neutron.<br>
><br>
> Secondly, the Neutron refactor will
be getting rid of<br>
> all the things<br>
> like $LB_INTERFACE_MAPPINGS - I
would *much* prefer<br>
> that someone using<br>
> DevStack actually set the
apropriate line in their<br>
> local.conf<br>
><br>
> Such as:<br>
><br>
>
[[post-config|/$Q_PLUGIN_CONF_FILE]]<br>
> [linux_bridge]<br>
> physical_interface_mappings =
foo:bar<br>
><br>
><br>
> The advantage of this is, when
someone is working with<br>
> DevStack, the<br>
> things they are configuring are the
same as all the<br>
> other OpenStack documentation.<br>
><br>
> For example, someone could read the
Networking Guide,<br>
> read the example<br>
> configuration[3] and the only thing
they'd need to<br>
> learn is our syntax<br>
> for specifying what file the
contents go in (the<br>
>
"[[post-config|/$Q_PLUGIN_CONF_FILE]]" piece).<br>
><br>
> Thoughts?<br>
><br>
> [1]:<br>
> <a moz-do-not-send="true"
href="https://github.com/openstack-dev/devstack/blob/1195a5b7394fc5b7a1cb1415978e9997701f5af1/lib/neutron_plugins/linuxbridge_agent#L63"
rel="noreferrer" target="_blank">https://github.com/openstack-dev/devstack/blob/1195a5b7394fc5b7a1cb1415978e9997701f5af1/lib/neutron_plugins/linuxbridge_agent#L63</a><br>
><br>
> [2]: <a moz-do-not-send="true"
href="https://review.openstack.org/168438"
rel="noreferrer" target="_blank">https://review.openstack.org/168438</a><br>
><br>
> [3]:<br>
> <a moz-do-not-send="true"
href="http://docs.openstack.org/liberty/networking-guide/scenario-classic-lb.html#example-configuration"
rel="noreferrer" target="_blank">http://docs.openstack.org/liberty/networking-guide/scenario-classic-lb.html#example-configuration</a><br>
><br>
><br>
><br>
><br>
><br>
><br>
>
__________________________________________________________________________<br>
> OpenStack Development Mailing List (not for
usage questions)<br>
> Unsubscribe:<br>
> <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
>
__________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage
questions)<br>
> Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage
questions)<br>
Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>