On 03/04/15 04:52, Tzu-Mainn Chen wrote:
----- Original Message -----
On Thu, Apr 02, 2015 at 10:34:29AM -0400, Dan Prince wrote:
On Wed, 2015-04-01 at 21:31 -0400, Tzu-Mainn Chen wrote:
Hey all,
I've run into a requirement where it'd be useful if, as an end user, I
could inject
a personal ssh key onto all provisioned overcloud nodes.
Obviously this is something that not every user would need or want. I
talked about
some options with Dan Prince on IRC, and (besides suggesting that I bring
the
discussion to the mailing list) he proposed some generic solutions - and
Dan, please
feel free to correct me if I misunderstood any of your ideas.
The first is to specify a pre-set custom puppet manifest to be run when
the Heat
stack is created by adding a post_deployment_customizations.pp puppet
manifest to
be run by all roles. Users would simply override this manifest.
The second solution is essentially the same as the first, except we'd
perform
the override at the Heat resource registry level: the user would update
the
resource reference to point to a their custom manifest (rather than
overriding
the default post-deployment customization manifest).
Do either of these solutions seem acceptable to others? Would one be
preferred?
Talking about this a bit more on IRC this morning we all realized that
Puppet isn't a hard requirement. Just simply providing a pluggable
mechanism to inject this sort of information into the nodes in a clean
way is all we need.
Steve Hardy's suggestion here is probably the cleanest way to support
this sort of configuration in a generic fashion.
https://review.openstack.org/170137
I don't believe this solution runs post deployment however. So if
running a hook post deployment is a requirement we may need to wire in a
similar generic config parameter for that as well.
No that's correct, this will only run when the initial node boot happens
and cloud-init runs, so it is pre-deployment only.
If we need post-deployment hooks too, then we could add a similar hook at
the end of *-post.yaml, which pulls in some deployer defined additional
post-deployment config to apply.
Steve
Post-deployment hooks would definitely be useful; one of the things we'd like
to do is create a user with very specific permissions on various openstack-
related files and executables.
Having a placeholder resource for custom user deployments is one option
we could consider. Another option would be to add outputs into the
overcloud template which expose the server IDs of all the resource group
members. Something like:
outputs:
ComputeServers:
value: {get_attr: [Compute, attributes, nova_server_resource]}
...
This would allow the user to define their own standalone stacks which
create deployments for those servers. These stacks would have their own
user-controlled lifecycle, and it would be up to the user to re-run
stack-update on these stacks after the overcloud scales.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
