Open Stack

On 30.3.2017 14:58, Dan Prince wrote:
> There is one case that I was thinking about reusing this piece of code
> within a container to help initialize keystone endpoints. It would
> require some changes and updates (to match how puppet-* configures
> endpoints).
>
> For TripleO containers we use various puppet modules (along with hiera)
> to drive the creation of endpoints. This functionally works fine, but
> is quite slow to execute (puppet is slow here) and takes several
> minutes to complete. I'm wondering if a single optimized python script
> might serve us better here. It could be driven via YAML (perhaps
> similar to our Hiera), idempotent, and likely much faster than having
> the code driven by puppet. This doesn't have to live in os-cloud-
> config, but initially I thought that might be a reasonable place for
> it. It is worth pointing out that this would be something that would
> need to be driven by our t-h-t workflow and not a post-installation
> task. So perhaps that makes it not a good fit for os-cloud-config. But
> it is similar to the keystone initialization already there so I thought
> I'd mention it.

I agree we could have an optimized python script instead of puppet to do 
the init. However, os-cloud-config also doesn't strike me as the ideal 
place.

What might be interesting is solving the keystone init within containers 
along with our container entrypoint situation. We've talked earlier that 
we may have to build our custom entrypoints into the images as we 
sometimes need to do things that the current entrypoints don't seem fit 
for, or don't give us enough control over what happens. This single 
optimized python script for endpoint config you mentioned could be one 
of such in-image entrypoint scripts. We could build multiple different 
scripts like this into a single image and select the right one when 
starting the container (defaulting to a script that handles the usual 
"worker" case, in this case Keystone API).

This gets somewhat similar to the os-cloud-config usecase, but even if 
we wanted a separate repo, or even a RPM for these, i suppose it would 
be cleaner to just start from scratch rather than repurpose os-cloud-config.

Jirka

>
> Dan
>
> On Thu, 2017-03-30 at 08:13 -0400, Emilien Macchi wrote:
>> Hi,
>>
>> os-cloud-config was deprecated in the Ocata release and is going to
>> be
>> removed in Pike.
>>
>> TripleO project doesn't need it anymore and after some investigation
>> in codesearch.openstack.org, nobody is using it in OpenStack.
>> I'm working on the removal this cycle, please let us know any
>> concern.
>>
>> Thanks,
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>