On 25/06/14 10:52, James Polley wrote: > Until https://review.openstack.org/#/c/83250/, 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. > > https://review.openstack.org/#/c/83250/ 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. > > 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. > > There are two open patches which would break backwards compatibility and > only ever use the files in $TRIPLEO_ROOT: > > https://review.openstack.org/#/c/93981/ > https://review.openstack.org/#/c/97657/ > > 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. >
How about we: * parameterize as suggested by Fabio in the review @ https://review.openstack.org/#/c/97657/ * move setting of this param to more visible location (setup, like devtest_variables or testenv). We can then give this better visibility in the dev/test autodocs with a warning about the 'old' behaviour * add a deprecation warning to the code that reads from $CWD/tripleo-overcloud-passwords to say that this will now need to be set as a parameter in ... wherever. How long is a good period for this? I don't think we make much in terms of backwards compatibility guarantees right now do we? marios > 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. > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
