[openstack-dev] [TripleO] [Heat] os-cloud-config ssh access to cloud

Steven Dake sdake at redhat.com
Fri Mar 14 14:32:57 UTC 2014


On 03/14/2014 07:14 AM, Jiří Stránský wrote:
> On 14.3.2014 14:42, Steven Dake wrote:
>> On 03/14/2014 06:33 AM, Jiří Stránský wrote:
>>> On 12.3.2014 17:03, Jiří Stránský wrote:
>>>>
>>>> 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/
>>>>
>>>
>>> I'm adding [Heat] to the subject. After some discussion on IRC it
>>> seems that what we need to do with Heat is not totally straightforward.
>>>
>>> Here's an attempt at a brief summary:
>>>
>>> In TripleO we deploy OpenStack using Heat, the cloud is described in a
>>> Heat template [1]. We want to externally generate and then upload 3
>>> small binary files to the controller nodes (Keystone PKI key and
>>> certificates [2]). We don't want to generate them in place or scp them
>>> into the controller nodes, because that would require having ssh
>>> access to the deployed controller nodes, which comes with drawbacks 
>>> [3].
>>>
>>> It would be good if we could have the 3 binary files put into the
>>> controller nodes as part of the Heat stack creation. Can we include
>>> them in the template somehow? Or is there an alternative feasible
>>> approach?
>>>
>> Jirka,
>>
>> You can inject files via the heat-cfntools agents.  Check out:
>> http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-init.html#aws-resource-init-files 
>>
>>
>> You could also use raw cloudinit data to inject a files section.
>>
>> There may be a final option with software config, but I'm not certain if
>> software config has grown a feature to inject files yet.
>>
>> Regards
>> -steve
>>
>
> Are these approaches subject to size limits? In the IRC discussion a 
> limit of 16 KB came up (i assumed total, not per-file), which could be 
> a problem in theory. The files `keystone-manage pki_setup` generated 
> for me were about 7.2 KB which gives about 10 KB when encoded as 
> base64. So we wouldn't be over the limit but it's not exactly 
> comfortable either (if that 16 KB limit still applies).
>
> Thanks
>
> Jirka
>
Jirka,

Yes these are limited by the metadata limit size, which on last 
inspection of the nova db code was approximately 16kb.

If software config supports file injection, it may not be subject to 
size limits.  Steve baker would have a better handle on that.

Another option is to load the data in swift and access from inside the 
vm on boot.  I know that is kind of hacky.  I think the default limit 
for nova is too small, but the data consumption adds up per vm in the 
database.

Regards
-steve

> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list