<div dir="ltr">Until <a href="https://review.openstack.org/#/c/83250/" target="_blank">https://review.openstack.org/#/c/83250/</a>, the setup-*-password scripts used to drop password files into $CWD, which meant that if you ran the script from a different location next time, your old passwords wouldn't be found.<div>


<br></div><div><a href="https://review.openstack.org/#/c/83250/" target="_blank">https://review.openstack.org/#/c/83250/</a> changed this so that the default behaviour is to put the password files in $TRIPLEO_ROOT; but for backwards compatibility we left the script checking to see if there's a file in the current directory, and using that file in preference to $TRIPLEO_ROOT if it exists.<br>


</div><div><br></div><div>However, this behaviour is still confusing to people. I'm not entirely clear on why it's confusing (it makes perfect sense to me...) but I imagine it's because we still have the problem that the code works fine if run from one directory, but run from a different directory it can't find passwords.</div>


<div><br></div><div>There are two open patches which would break backwards compatibility and only ever use the files in $TRIPLEO_ROOT:</div><div><br></div><div><a href="https://review.openstack.org/#/c/93981/" target="_blank">https://review.openstack.org/#/c/93981/</a><br>


</div><div><a href="https://review.openstack.org/#/c/97657/" target="_blank">https://review.openstack.org/#/c/97657/</a><br></div><div><br></div><div>The latter review is under more active development, and has suggestions that the directory containing the password files should be parameterised, defaulting to $TRIPLEO_ROOT. This would still break for anyone who relies on the password files being in the directory they run the script from, but at least there would be a fairly easy fix for them.</div>

<div><br></div><div>To help decide if it's time to break backwards compatibility in this case (and if so, how), I'd love to see some more comments on 97657. If we don't want to break backwards compatibility, maybe comments about a better way to handle the ambiguity would be helpful.</div>

</div>