On 06/25/2014 11:25 AM, mar...@redhat.com wrote:
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?
+1
actually, I have probably being the first suggesting that we should
parametrize the path to the password files so I want to add my
motivations here
the big win that I see here is that people may want to customize only
some of the passwords, for example, the undercloud admin
the script creating the password files is *already* capable of pushing
in the file only new passwords, without regenerating passwords which
could have been manually set in there already
this basically implements the 'feature' I mentioned except people just
doesn't know it!
so I'd like we to expose this as a feature, from the early stages as
Marios suggests too, maybe from devtest_variables
--
Giulio Fidente
GPG KEY: 08D733BA
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
