<div dir="ltr">Hello, Sean.<div><br></div><div>I get the issue with upgrade path. User doesn't want to update config unless one is forced to do so.</div><div>But introducing code that weakens security and let it stay is an unconditionally bad idea. </div>

<div class="gmail_extra">It looks like we have to weigh two evils: having troubles upgrading and lessening security. That's obvious.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Here are my thoughts on what we can do with it:</div>

<div class="gmail_extra">1. I think we should definitely force user to do appropriate configuration to let us use secure ways to do locking.</div><div class="gmail_extra">2. We can wait one release to do so, e.g. issue a deprecation warning now and force user to do it the right way later.</div>

<div class="gmail_extra">3. If we are going to do 2. we should do it in the service that is affected not in the library because library shouldn't track releases of an application that uses it. It should do its thing and do it right (secure).</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">So I would suggest to deal with it in Cinder by importing 'lock_path' option after parsing configs and issuing a deprecation warning and setting it to tempfile.gettempdir() if it is still None.</div>

<div class="gmail_extra"><div><br></div>-- <br><br><div>Kind regards, Yuriy.</div>
</div></div>