Open Stack

On 06/25/2014 11:25 AM, marios at 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