Open Stack

On 15/03/14 02:33, 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?
>
>
> Thank you
>
> Jirka
>
> [1]
> https://github.com/openstack/tripleo-heat-templates/blob/0490dd665899d3265a72965aeaf3a342275f4328/overcloud-source.yaml
> [2]
> http://docs.openstack.org/developer/keystone/configuration.html#install-external-signing-certificate
> [3]
> http://lists.openstack.org/pipermail/openstack-dev/2014-March/029327.html

It looks like the cert files you want to transfer are all ascii rather
than binary, which is good as we have yet to implement a way to attach
binary data to a heat stack create call.

One way to write out these files would be using cloud-config. The
disadvantages of this is that it is boot-time config only, so those keys
couldn't be updated with a stack update. You would also be consuming a
decent proportion of your 16k user_data limit.

  keystone_certs_config:
    Type: OS::Heat::CloudConfig
    Properties:
      cloud_config:
        write_files:
        - path: /etc/keystone/ssl/certs/signing_cert.pem
          content: |
            # You have 3 options for how to insert the content here:
            # 1. inline the content
            # 2. Same as 1, but automatically with your own template
pre-processing logic
            # 3. call {get_file: path/to/your/signing_cert.pem} but this
only works for HOT syntax templates
          permissions: '0600'

  keystone_init:
    Type: OS::Heat::MultipartMime
    Properties:
      parts:
      - subtype: cloud-config
        config:
          get_resource: keystone_certs_config
  notCompute0:
    Type: OS::Nova::Server
    Properties:
      user_data: {Ref: keystone_init}

But it looks like you should just be using os-apply-config templates for
all of the files in /etc/keystone/ssl/certs/

  notCompute0Config:
    Type: AWS::AutoScaling::LaunchConfiguration
    ...
    Metadata:
      ...
      keystone:
        signing_cert: |
          # You have 3 options for how to insert the content here:
          # 1. inline the content
          # 2. Same as 1, but automatically with your own template
pre-processing logic
          # 3. call {get_file: path/to/your/signing_cert.pem} but this
only works for HOT syntax templates

If the files really are binary then currently you'll have to encode to
base64 before including the content in your templates, then have an
os-refresh-config script to decode and write out the binary files.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140317/af4ef023/attachment.html>