Re: [openstack-dev] [TripleO] [Heat] os-cloud-config ssh access to cloud
On 16.3.2014 21:20, Steve Baker wrote:
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.
Ah i don't know why i thought .pem files were binary. Thank you Steve,
your reply is super helpful :)
Jirka
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Heat] os-cloud-config ssh access to cloud
On 17 March 2014 10:32, Steve Baker wrote: > On 17/03/14 10:14, Robert Collins wrote: >> On 17 March 2014 09:20, Steve Baker wrote: >> >>> 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. >> I'm confused - why can't we include them in the template? We include >> an SSH key in ascii form already with no issue. >> > You can include them in the template. That template snippet shows how to > specify cloud-config in the template. However I would recommend just > going with the os-apply-config templates (the second option in that > email). I probably shouldn't have mentioned cloud-config as an option at > all. Righto - thats what I meant. Shove it in heat, pull it out in heat metadata, apply via o-a-c. -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Heat] os-cloud-config ssh access to cloud
On 17 March 2014 09:20, Steve Baker wrote: > 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. I'm confused - why can't we include them in the template? We include an SSH key in ascii form already with no issue. -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Heat] os-cloud-config ssh access to cloud
On 17/03/14 10:14, Robert Collins wrote: > On 17 March 2014 09:20, Steve Baker wrote: > >> 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. > I'm confused - why can't we include them in the template? We include > an SSH key in ascii form already with no issue. > You can include them in the template. That template snippet shows how to specify cloud-config in the template. However I would recommend just going with the os-apply-config templates (the second option in that email). I probably shouldn't have mentioned cloud-config as an option at all. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Heat] os-cloud-config ssh access to cloud
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.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Heat] os-cloud-config ssh access to cloud
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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Heat] os-cloud-config ssh access to cloud
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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Heat] os-cloud-config ssh access to cloud
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 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Heat] os-cloud-config ssh access to cloud
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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
