Open Stack

On Tue, Aug 15, 2017 at 7:36 AM, Lance Bragstad <lbragstad at gmail.com> wrote:
> During RC, Morgan's made quite a bit of progress on a bug found by the
> gate [0]. Part of the solution led to another patch that removes the
> ability to configure anything but sql for keystone's resource backend
> (`keystone.conf [resource] driver`). The reasoning behind this is that
> there were FK constraints introduced between the identity and resource
> tables [1] during the Ocata development cycle. This leaves us with two
> options moving forward:
>
> 1.) Drop the FK constraints entirely and backport those
> migrations/models to Ocata
> 2.) Ensure the resource backend is always configured as SQL - and keep
> the FKs setup between the resource and identity tables (note; this
> doesn't prevent the usage of non-sql identity backends, but just ensures
> that when sql is used for identity, resource is also used).
>
> Sending this out as a heads up for those deployments that might fall
> into this category. Let me know if you have any questions.
>
> Thanks,
>
> Lance
>
>
> [0] https://launchpad.net/bugs/1702211
> [1]
> https://github.com/openstack/keystone/commit/2bd88d30e1d2873470af7f40db45a99e07e12ce6
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

The removal of the FKs also requires backporting schema updates (which
is both painful and much higher risk). As it stands it is highly
unlikely anyone is using non-SQL resource backends as any use of the
SQL Identity backend requires resource to be SQL. The Resource data is
highly relational and very keystone/openstack specific. The lowest
impact choice is to make [resource] always SQL.