<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><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 11, 2016 at 3:55 PM, Brandon Logan <span dir="ltr"><<a 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 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 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 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 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 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 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 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 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 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 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 href="https://review.openstack.org/168438" rel="noreferrer" target="_blank">https://review.openstack.org/168438</a><br>
><br>
> [3]:<br>
> <a 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 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 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 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 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 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 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>