Open Stack

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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>