Open Stack

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