On 21/02/14 10:38, Dougal Matthews wrote: > On 21/02/14 09:24, Tomas Sedovic wrote: >> On 20/02/14 16:24, Imre Farkas wrote: >>> 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. >> >> Well if that is the case and we can't change the templates/heat to >> change that, the secrets should be put in Keystone or at least go >> through Keystone. Or use Barbican or whatever. >> >> We shouldn't be implementing crypto in Tuskar. > > +1, after giving this quite a bit of thought i completely agree. This > is really out of the scope of Tuskar. I think we should definitely go > down this route and only fall back to storing all these details > later, that could be an improvement if it turns out to be a real > usability problem. > > At the moment we are guessing, we don't even know how many passwords > we need to store. So we should progress with the safest and simplest > option (which is to not store them) and consider changing this later.
I think we have a pretty good idea: https://github.com/openstack/tuskar-ui/blob/master/tuskar_ui/infrastructure/overcloud/workflows/undeployed_configuration.py#L23-L222 (just count the "NoEcho": "true" lines) -- Radomir Dopieralski _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
