Per the past year of discussions, culminating in the most recent
mailing list thread[*], it's apparent that providing a consistent
solution for storage of key material and similar secrets by security
features of various OpenStack services is in the best interests of
the project. By providing this guarantee in the base services set,
projects don't need to worry about implementing insecure fallback
alternatives or needlessly duplicating functionality to cope with
the lack of an already-available solution.
[*] http://lists.openstack.org/pipermail/openstack-dev/2018-May/130567.html
Change-Id: Ia46211f41726d5671bf28a632d17fc56965b6fcc
It was pointed out in #openstack-tc[*] that we may be making some
assumptions about the reasons for base services without having fully
expressed them in any durable form. As an example, when we added a
distributed lock manager to this list the driving reason was that
several services had already implemented their own (some completely
independently, some by copying from other services and then perhaps
making modifications). There are times when we solve this problem by
adding new shared libraries, hence the remit of Oslo, but some
solutions need full-blown services in their own right which may or
may not be developed within the OpenStack community.
We also realize that deployments may be hesitant to turn on useful
features by default because they rely on yet another service, and
this hampers adoption of something which if ubiquitous would perhaps
snowball into the addition of similar useful default capabilities
in OpenStack deployments.
[*] http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-05-16.log.html#t2018-05-16T17:55:51
Change-Id: Ie85658e95dad210ea8ef838eb2fb5a571ed02cab
There have been a lot of discussions around scenarios like
distributed locks, storing additional configuration information
and coordinating service liveness checks without using a database
etc. Example:
http://lists.openstack.org/pipermail/openstack-dev/2015-November/thread.html#78214http://lists.openstack.org/pipermail/openstack-dev/2017-March/thread.html#113941http://lists.openstack.org/pipermail/openstack-dev/2017-March/thread.html#113885
So at the Boston Summit Forum, we had a session on a specific proposal
to consider Etcd 3.x for such scenarios:
https://etherpad.openstack.org/p/BOS-etcd-base-service
There was consensus in the room based on which a bunch of work
was done in tooz, devstack etc after thorough research on the
options available for both eventlet and non-eventlet based services.
The consensus grew around folks using oslo library like tooz or if
they choose, they can directly use etcd using python client
libraries like etcd3 (for non-eventlet scenarios) and etcd3gw (for
eventlet based scenarios). We should be using the v3 APIs using
the etcd 3.1.x versions to avoid migration issues from the older
v2 APIs.
Change-Id: Id6dd2a8fffd50dca8f0de05def20d31bf9c61717
Introduce the concept of "base services" (external services that
OpenStack components can assume will be present in any OpenStack
installation) and list current base services.
This is intended to reflect the current situation. Changes to the
list should be proposed as subsequent patches.
You can find a more detailed analysis and rationale for this change
in the Architecture WG analysis:
http://git.openstack.org/cgit/openstack/arch-wg/tree/active/base-services.rst
Change-Id: I77ffc000d895c3d8eb27b3b821c6c63f9dd2f675
Jeremy Stanley