This change sync's oslo-incubator's db module from commit hash
6ba44fd7f9d39a7930defb4e14c37b8b1046cbcb
$ python update.py --nodeps --base keystone \
--dest-dir ../keystone \
--modules db,db.sqlalchemy,gettextutils
- Config options were moved from db.sqlalchemy.session to db.options
- db.sqlalchemy.session doesn't provide get_session, get_engine, or
cleanup functions.
- db.sqlalchemy.migration.db_version() requires an engine parameter
Closes-Bug: #1227321
Change-Id: I742cef9dab68d9eed977df0039736cfe67ca493c
Add the last of the outstanding help strings to the options defined
in keystone.common.config.
Adds in periods to the end of the helpstrings that were missing
proper ending punctuation.
DocImpact
Related-Bug: #1229941
Change-Id: Iebe0358a19f645220eb7b3dfca0dc868716f5bc8
Base API for reporting revocation events.
The KVS Backend uses the Dogpile backed KVS stores.
Modifies the places that were directly deleting tokens to also generate
revocation events.
Where possible the revocations are triggered by listening to the notifications.
Some places, the callers have been modified instead. This is usually due to
the need to iterate through a collection, such as users in a group.
Adds a config file option to disable the existing mechanisms that support
revoking a token by that token's id: revoke_by_id. This flag is necessary
to test that the revocation mechanism is working as defined, but will also
be part of the phased removal of the older mechanisms. TokenRevoke tests
have been extended to test both with and without revoke-by-id enabled.
Note: The links aren't populated in the list_events response.
SQL Backend for Revocation Events
Initializes the SQL Database for the revocation backend.
This patch refactors the sql migration call from the CLI
so that the test framework can use it as well. The sql
backend for revcations is exercized by test_notifications
and must be properly initialized.
Revoke By Search Tree
Co-Authored-By: Yuriy Taraday (Yoriksar)
create a set of nested maps for the events. Look up revocation by
traversing down the tree.
Blueprint: revocation-events
Change-Id: If76c8cd5d01a5b991c58a4d1a9d534b2a3da875a
Remove the "pam" configuration options that were only ever used for
testing purposes. Removes the test config file "backend_pam.conf"
by moving test_backend_pam.py to utilize proper configuration fixture
for identity driver. Since we no longer need the "pam.user" and
"pam.password" config options.
DocImpact
Related-Bug: #1229941
Change-Id: I3759ff7974948432900e3a73f3d87e5eed6e9828
The rpc module was a dependency that was needed for the notifier module.
Since the notifier and rpc modules have been incorporated into oslo.messaging,
there is no need for the sync'd versions from oslo-incubator. This change
removes the oslo-incubator rpc module.
Change-Id: I00f7ae3e71c0df0de22e1371c6eee372230384f2
Blueprint: oslo-messaging
This updates the log module from oslo-incubator to
a01f79c3050962fd744239956e9654407d14ea1f
$ git checkout a01f79c3050962fd744239956e9654407d14ea1f
$ python update.py --nodeps --base keystone \
--dest-dir ../keystone --modules log
This includes a fix for the deprecated logger that caused the
deprecated message to be printed multiple times rather than once.
Change-Id: I6174b064205adcdc9fb966a9e01eb5190b5b730e
Closes-Bug: #904307
Closes-Bug: #1266812
Restructure the common config to include many help strings to
support using the oslo.config auto-generated sample config file.
Closes-Bug: #1229941
Change-Id: If352b3b816b1e7dc8b5fc3b9c1cb2adab187ffda
Oslo messaging works slightly differently in that you create a Notifier
object once which contains config such as publisher_id and then you
re-use that object when issuing messages.
DocImpact: The options for setting up RPC and notifications have changed
to reflect oslo.messaging.
Blueprint: oslo-messaging
Change-Id: I2d08fb405e68df37866b3799ab7339ebd9894f05
The https://review.openstack.org/#/c/66247/ change introduced
the requirement to set config_file before keystone would start
up. Restore the old setting as default to allow a smooth
transition for users.
Change-Id: I935c5144728d04c59abaee9a515e249ef0d24477
Provides an optional limit to the number of rows that will be
returned by a backend from a list_{entity} call. The limit is specified
in the configuration file, and allows for an overall general limit as
well as an individual limit for a given driver. By default, there is
no limit.
Limitations:
- The list limit is not yet handled by LDAP, rather this remains
implemented in the final wrap collection - a subsequent patch
will provide the support in the LDAP drivers
Implements bp list-limiting
Change-Id: I7ca76a8da4260242e578c44103b26257f7e2a5d5
This config option is used when you use the notify_wrapper wrapper
function from openstack.common. As we don't use the wrapper we don't
ever require the config option so we shouldn't show it to users.
blueprint oslo-messaging
Change-Id: I95280af37a84c71131fb2fc92c9302b8926c95bd
Keystone's db.sqlalchemy.session module was out of date. This
updates Keystone's version to oslo-incubator hash
01813871e2f6b9b01783f7da88998d9bc97d4a8c .
$ python update.py --nodeps --base keystone \
--dest-dir ../keystone --modules db.sqlalchemy.session
Among other changes, the newer db.sqlalchemy.session has fixes to
the docstring so there are fewer warnings issued during doc build
and rendering issues.
Change-Id: I70f6727adeb98142f8a9a1cea04c71ade27dfaba
Currently the wsgi server will not close connections once requests
complete and will not enable keepalive on it's wsgi sockets. This can
be a problem for those who need to align the server keepalive with
load balancer timeouts without modifying system keepalive settings.
To remedy this we add new config options tcp_keepalive and
tcp_keepidle which are disabled by default to remain backwards
compatible.
DocImpact: "new config options for wsgi tcp_keepalive & tcp_keepidle"
Closes-bug: bug 1260406
Co-authored-by: Hirofumi Ichihara <ichihara.hirofumi@lab.ntt.co.jp>
Change-Id: Ic53402c57e1ebe44cde4c18e5e15200dcbbcb04b
The default for default_log_levels didn't set the log levels
for some packages that Keystone uses (for example, dogpile). This
caused the server to output a lot of extra logs when debug=True
is used.
You can get the debug output for dogpile and routes by setting
default_log_levels explicitly in your keystone.conf file.
Change-Id: Ib797fa7b98f0e501047b72b094d07ad204385cc6
Related-bug: #1245629
Closes-Bug: #1269987
The documentation of the default_log_levels default value in the
sample keystone.conf file was out of date. The default value has
been updated to the current value in keystone.openstack.common.log.
Change-Id: I3edf2d5375413250de41f8cebb98a826dc5df8ce
This addresses a long standing TODO for consistency across catalog
drivers, making it more intuitive to switch drivers.
UpgradeImpact
Change-Id: I109513695e60867d1111795ab958a3cc4240e831
- reduces number of active tokens that have to be persisted, especially
where clients are needlessly regenerating tokens
- reduces the window of publishing token revocation events (you only
have to publish events from the last hour)
- reduces the window of the token revocation list (similar to the above)
DocImpact
UpgradeImpact
Implements: bp reduce-default-token-duration
Change-Id: Ia548f7e981690edab56c51fdcab9102245aced3e
The sample config file documented the incorrect default for the
[auth].external value as defined in keystone.common.config.
Change-Id: I6f9454f35eaade5fa35738a9ba3f74a388bf5099
It seems that there is a misconception around the ADMIN_TOKEN in
keystone. Currently the comment read that it is a "shared secret"
and can be used between openstack services.
However this token has no user associated with it, and no
authorization. It's a method to bootstrap into keystone, that's
all.
Closes-Bug: 1261622
Co-Authored-By: Dolph Mathews <dolph.mathews@gmail.com>
Change-Id: I6c913a8079bb84b56ac69249e7d25bc94cf32dd0
Keystone was using its own keystone.common.sql module for
database access. oslo-incubator's db.sqlalchemy module provides
the same or better functionality, so use that instead.
DocImpact
- The options that were in the [sql] section are deprecated and
replaced by options in the [database] section. There are
also several new options in this section. If database
configuration is described for another project that uses
oslo-incubator's db.sqlalchemy module the docs can be shared.
Part of bp use-common-oslo-db-code
Change-Id: I25b717d9616e9d31316441ae3671d2f86229c2bf
This changeset implements a KVS interface that makes use of
dogpile's backends. Included is an in-memory database (primarily
to be used for testing) that isolates data from modification via
liberal use of copy.deepcopy. The memcached backend is a manager
pivot to allow the use of the various dogpile.cache memcache
backends while maintaining a simplified interface.
The KVS system implements a Distributed-Capable locking system that
hooks into the dogpile.cache backend mutexes. Locking can be
toggled at configuration time for a given KeyValueStore
instantiation.
The original kvs implementation has been moved to
keystone.common.kvs.legacy. For compatibility all elements of the
old keystone.common.kvs namespace have been made available at
keystone.common.kvs. The legacy kvs implementation has been marked
for deprecation after the release of ICEHOUSE.
DocImpact
bp: dogpile-kvs-backends
Change-Id: I8af1adfcb181f9118a1f21aada2e000c6cc0c201
The memcache options from keystone.common.config weren't included
in the sample config file (keystone.conf.sample).
Having these options in the sample config file makes it easier to
update them when using the memcache token backend.
Change-Id: I49b5c928bcc7f170f049277c7dad0bae58b1504e
Keystone supports configuration of an admin_port and a public_port.
Applications may well want the admin port to be open on a different private network.
This patch change single bind_host to public_bind_host and admin_bind_host in the configuration.
DocImpact
Change-Id: Ic91aade987724c8f7c9276ca94e27681ae590662
Closes-Bug: #1035326
LDAP Identity backend is not domain aware, and therefore does not
need mappings for the domain attributes for user and group.
closes-bug: 1209440
Change-Id: Ib7b77b90134322d04b5826b151d05535b9b8b7c7
This patchset normalizes the use of tenantId, tenant_id, and
default_project_id across the Identity backend. This includes
making default_project_id no longer part of the "extra" json blob
on the user object and migrating all "tenantId" "tenant_id" and
"default_project_id" into the new column (SQL).
In the LDAP driver, None is set as the mapping for
default_project_id. This means that use of default_project_id with
LDAP Identity will require an explicit mapping to be defined by the
cloud operator.
"default_project_id" remains (by default) configured to be in the
"ignore" attributes for the LDAP driver, so 'tenantId' and
'default_project_id' will not be saved on the user_object during
update or create unless Keystone is explicitly configured to do so.
closes-bug: 1219739
closes-bug: 1226475
related-bug: 1201251
Change-Id: I07f9dfe111646884ac5efd42fc8c2974188b3b94
Some new configuration options were added with the change to add
notifications to Keystone, but these new options weren't added
to the sample config file.
This change adds the new options to the sample configuration
file along with the descriptions from
keystone.openstack.common.notifier.api.
Also, if the Keystone server uses the RPC options from
keystone/openstack/common/rpc/__init__.py if using the RPC
notification driver, so these options are also added to the
sample config file.
Having these options in the config file will make it easier for
administrators to update the configuration values.
DocImpact
Change-Id: I85f2450a6fb68d51453adbb5413ad48fe00ca17e
Password protection in the current implementation is not actually
applied despite the presence of the ca_password config
option. Password protection is of marginal benefit because the
password must be stored in a file using the same protections afforded
to the key file. Password protection currently is not utilized with
externally provided keys.
Remove the ca_password config option and remove the use of the various
password related options to the OpenSSL commands whose net effect was
not actually accomplishing anything.
See the bug report for a thorough description of the issues.
Change-Id: Iaeb97f2338c4d3c6e770b410dee8f1b62778b561
Fixes: Bug #1214016