On 02/24/2014 09:39 AM, Ladislav Smola wrote:
On 02/23/2014 01:16 AM, Clint Byrum wrote:
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.
Do we actually need to expose to the user something else than
AdminPassword?
I think we should not. The MySQL password or any of the service
passwords are "implementation details" of the cloud, it should not be
used by anyone, except for OpenStack internally. The administrator
should setup separate user accounts with the proper privileges to access
these services.
Imre
We are using tripleo-heat-templates currently, so we will need to make
the change
there.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
