[openstack-dev] [tripleo] os-cloud-config retirement

Jiří Stránský jistr at redhat.com
Fri Mar 31 11:58:09 UTC 2017


On 30.3.2017 17:39, Juan Antonio Osorio wrote:
> Why not drive the post-config with something like shade over ansible?
> Similar to what the kolla-ansible community is doing.

We could use those perhaps, if they bring enough benefit to add them to 
the container image(s) (i think we'd still want to drive it via a 
container rather than fully externally). It's quite tempting to just 
load a yaml file with the endpoint definitions and just iterate over 
them and let Ansible handle the actual API calls...

However, currently i can't see endpoint management in the cloud modules 
docs [1], just service management. Looks like there's still a feature 
gap at the moment.

Jirka

[1] http://docs.ansible.com/ansible/list_of_cloud_modules.html#openstack

>
> 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
>>
>
>
>
> __________________________________________________________________________
> 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
>




More information about the OpenStack-dev mailing list