Open Stack

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.