This commit lays down the policies needed to protect the unified limit
API. A subsequent patch will expose the implementation.
bp unified-limits
Change-Id: I952fe6213adce86a92d7d607c9b639076b279f6c
This patch does:
1. Improve the error message as Morgan suggested before.
2. Add a new error type: RegisteredLimitError.
3. Catch the DBReferenceError in update/delete resigtered limit
functions.
4. Handle the case that region_id=None for update/delete
registered limits.
5. Fix a code error in create_limits function.
Change-Id: Id572348ca7867d7ce6f258cb3132b05a313624bd
bp: unified-limits
Keystone has APIs for retrieving projects and domains based on the
role assignments a user has on projects and domains. We should
introduce similar functionality for system assignments. This will
make discovering system access for users and client easier.
bp system-scope
Change-Id: Iab577fcd1b57b8b5593c3f9d50a772466383a999
Since grants can exist on either the system or a project, it makes
sense to have them associated to both `system` and `project` scopes.
But until we have logic in keystone that can enforce those checks, we
keep the scope_types set to `system`. This ensures backwards
compatibility and helps resolve admin-ness issues until we get to
that point.
Change-Id: I310c88bae7986e3163408f621e266f96fd255edc
MariaDB 10.2 introduced an issue where an automatic check constraint is
applied to boolean columns and is not automatically updated on a column
rename alter operation[1]. A similar issue preventing dropping such a
column was already fixed[2], so this patch changes the migration to drop
and readd the column instead of attempting a column rename.
Unfortunately since the mistake was already made, it is possible for
deployments out in the wild to have made it past the expand step and be
currently stuck in the contract step. To accomodate them, we add the new
column as part of the contract step if necessary. Again, since there
should be no data in this table, we don't need to worry about online
upgrades here.
[1] https://jira.mariadb.org/browse/MDEV-13508
[2] https://jira.mariadb.org/browse/MDEV-11114
Change-Id: Icbd58464182b082854fb5d73ccc93c900ede020c
Closes-bug: #1744948
Now registered limit table has two foreign keys, one for service
id, another for region id. But catalog and limit may use different
backend, in that case, the fks will lead error. Such as, if catalog
use file based backend, registered limit will can never be created.
So we should drop the fks in the table and add the resouce existence
check logic in code.
Change-Id: Ic98e069a03931bb3eaaad63cd2db7e6a822a3546
bp: unified-limits
This commit consists of some utilities that we can use when testing
system-scoped tokens. A subsequent patch will use them when
implementing the tests.
bp system-scope
Change-Id: If011ff7630cda1f7330a7657dd8e6249f0af5442
This change incorporates system-scope changes into the token provider
API. A subsequent patch will wire up the necessary controller bits
that expose the functionality via the API.
bp system-scope
Change-Id: I15ed4b96d3e0d78f85ca61a3d85274c770c4c7cf
This commit adds a new payload type that is meant to allow
system-scoped token. A subsequent patch will actually wire this up
to the token provider API and another patch to expose it via the
authentication API.
bp system-scope
Change-Id: I26357b6d62ce88ad116e0231145b2367dda62fa2
Since it's possible to have a role assignment on the system now, we
should make sure we handle that case in the RoleAssignmentNotFound
exception
bp system-scope
Change-Id: I2388d65ffa5b68690d9c4f0dd16f16e158f5a091
In the application credential spec[1] we decided to add on a parameter
that would control whether an application credential could be used to
create other application credentials. This parameter is also used to
control whether it can be used to delete other application credentials
and whether it can create and delete trusts. Therefore the name
`allow_application_credential_creation` is misleading. Moreover, giving
a property of the resource a name that is an imperative verb is not
great. It makes more sense for a property to be a noun, an adjective, or
a passive verb.
This change renames the `allow_application_credential_creation`` column
to ``unrestricted``. This maintains the same boolean context, i.e. a
"true" value for the old name maintains the same meaning as a "true"
value for the new name.
At this point, the application credential API has not yet been exposed,
so there should be no data in this table and no need for complicated
migration triggers. In general, we only need to do a column alter to
rename it. Sqlite is special because it does not support column alters,
so in order to accomodate our tests the migration involves copying the
whole table, minus the old column, and recreating it with the new
column.
Change-Id: Id26a2790acae25f80bd28a8cb121c80cb5064645