[openstack-dev] [tripleo] os-cloud-config retirement
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 , just service management. Looks like there's still a feature
gap at the moment.
> 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
>>> 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
>> 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.
>>> On Thu, 2017-03-30 at 08:13 -0400, Emilien Macchi wrote:
>>>> os-cloud-config was deprecated in the Ocata release and is going to
>>>> 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
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev