Excerpts from Imre Farkas's message of 2014-02-20 15:24:17 +0000: > On 02/20/2014 03:57 PM, Tomas Sedovic wrote: > > On 20/02/14 15:41, Radomir Dopieralski wrote: > >> On 20/02/14 15:00, Tomas Sedovic wrote: > >> > >>> Are we even sure we need to store the passwords in the first place? All > >>> this encryption talk seems very premature to me. > >> > >> How are you going to redeploy without them? > >> > > > > What do you mean by redeploy? > > > > 1. Deploy a brand new overcloud, overwriting the old one > > 2. Updating the services in the existing overcloud (i.e. image updates) > > 3. Adding new machines to the existing overcloud > > 4. Autoscaling > > 5. Something else > > 6. All of the above > > > > I'd guess each of these have different password workflow requirements. > > I am not sure if all these use cases have different password > requirement. If you check devtest, no matter whether you are creating or > just updating your overcloud, all the parameters have to be provided for > the heat template: > https://github.com/openstack/tripleo-incubator/blob/master/scripts/devtest_overcloud.sh#L125 > > I would rather not require the user to enter 5/10/15 different passwords > every time Tuskar updates the stack. I think it's much better to > autogenerate the passwords for the first time, provide an option to > override them, then save and encrypt them in Tuskar. So +1 for designing > a proper system for storing the passwords.
Tuskar does not need to reinvent this. Use OS::Heat::RandomString in the templates. If any of them need to be exposed to the user, use an output on the template. If they need to be regenerated, you can pass a "salt" parameter. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
