[Openstack-operators] [openstack-dev] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka

Thomas Goirand zigo at debian.org
Wed Dec 9 21:04:32 UTC 2015

On 12/08/2015 06:39 AM, Jamie Lennox wrote:
>     The main problem I see with running Keystone (or any other service) in a
>     web server, is that *I* (as a package maintainer) will loose the control
>     over when the service is started. Let me explain why that is important
>     for me.
>     In Debian, many services/daemons are run, then their API is used by the
>     package. In the case of Keystone, for example, it is possible to ask,
>     via Debconf, that Keystone registers itself in the service catalog. If
>     we get Keystone within Apache, it becomes at least harder to do so.
> I was going to leave this up to others to comment on here, but IMO -
> excellent. Anyone that is doing an even semi serious deployment of
> OpenStack is going to require puppet/chef/ansible or some form of
> orchestration layer for deployment. Even for test deployments it seems
> to me that it's crazy for this sort of functionality be handled from
> debconf. The deployers of the system are going to understand if they
> want to use eventlet or apache and should therefore understand what
> restarting apache on a system implies.

It is often what everyone from within the community says. However,
there's lots of users who hardly do a single deployment, maybe 2. I
don't agree that they should all invest a huge amount of time in some
automation tools, and for them, packages should be enough.

Anyway, the debconf handling is completely optional, and most of the
helpers are completely disabled by default. So it is *not* in the way of
using any deployment tool like puppet.


Thomas Goirand (zigo)

More information about the OpenStack-operators mailing list