<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Which ini file is active is a function of the packaging so it's upto<br>

the RPM and DEB folks notOpenStack upstream. teh<br>
/etc/neutron/plugin.ini abstraction is the RPM way, which I personally<br>
 like a bit better than the DEB way.<br></blockquote><div><br></div><div>+1</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What IU have discovered is is since all teh ini files specified on the<br>

lauch command line are sourced in teh same way it doesn't make any<br>
technical different if it's in /etc/neutron/plugin.ini<br>
/etc/neutron/plugins/ml2/ml2.ini or even /etc/neutron/neutron.conf<br>
(well except that breaking it into some different files means<br>
different service can start with different config values, can't think<br>
if that's actually useful now but it's good abstraction)<br></blockquote><div><br></div><div>+1</div><div><br></div><div>This is why in one of my lab/sandbox setups, I have opt'd to just clobber/overwrite the contents of whatever ini file the init script is pointing to rather than replacing the init script path. It doesn't matter what the ini file is called.</div>
<div><br></div><div>This is also why people are successful with adding "legacy" neutron ini settings to get ml2 to work, such as the various settings under [ovs] like local_ip and bridge_mappings.</div></div></div>
</div>