Open Stack

Why not drive the post-config with something like shade over ansible?
Similar to what the kolla-ansible community is doing.

On 30 Mar 2017 16:42, "Jiří Stránský" <jistr at redhat.com> wrote:

> 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:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170330/79ef5b2e/attachment.html>