Open Stack

On 11.3.2014 15:50, Adam Young wrote:
> On 03/11/2014 05:25 AM, Dmitry Mescheryakov wrote:
>> For what it's worth in Sahara (former Savanna) we inject the second
>> key by userdata. I.e. we add
>> echo "${public_key}" >> ${user_home}/.ssh/authorized_keys
>>
>> to the other stuff we do in userdata.
>>
>> Dmitry
>>
>> 2014-03-10 17:10 GMT+04:00 Jiří Stránský <jistr at redhat.com>:
>>> On 7.3.2014 14:50, Imre Farkas wrote:
>>>> On 03/07/2014 10:30 AM, Jiří Stránský wrote:
>>>>> Hi,
>>>>>
>>>>> there's one step in cloud initialization that is performed over SSH --
>>>>> calling "keystone-manage pki_setup". Here's the relevant code in
>>>>> keystone-init [1], here's a review for moving the functionality to
>>>>> os-cloud-config [2].
>
> You really should not be doing this.  I should never have written
> pki_setup:  it is a developers tool:  user a real CA and a real certificate.

Thanks for all the replies everyone :)

I'm leaning towards going the way Robert suggested on the review [1] - 
upload pre-created signing cert, signing key and CA cert to controller 
nodes using Heat. This seems like a much cleaner approach to 
initializing overcloud than having to SSH into it, and it will solve 
both problems i outlined in the initial e-mail.

It creates another problem though - for simple (think PoC) deployments 
without external CA we'll need to create the keys/certs 
somehow/somewhere anyway :) It shouldn't be hard because it's already 
implemented in keystone-manage pki_setup but we should figure out a way 
to avoid copy-pasting the world. Maybe Tuskar calling pki_setup locally 
and passing a parameter to pki_setup to override default location where 
new keys/certs will be generated?


Thanks

Jirka

[1] https://review.openstack.org/#/c/78148/