Jamie Lennox <jamielen...@redhat.com> writes: > ----- Original Message ----- >> From: "Noorul Islam K M" <noo...@noorul.com> >> To: "Dolph Mathews" <dolph.math...@gmail.com> >> Cc: "OpenStack Development Mailing List (not for usage questions)" >> <openstack-dev@lists.openstack.org> >> Sent: Friday, 7 February, 2014 2:00:34 PM >> Subject: Re: [openstack-dev] [keystone] Integrating with 3rd party DB >> >> Dolph Mathews <dolph.math...@gmail.com> writes: >> >> > On Thu, Feb 6, 2014 at 6:38 AM, Noorul Islam Kamal Malmiyoda < >> > noo...@noorul.com> wrote: >> > >> >> Hello stackers, >> >> >> >> We have a database with tables users, projects, roles, etc. Is there >> >> any reference implementation or best practices to make keystone use >> >> this DB instead of its own? >> >> >> > >> > What's the problem you're having? Does the schema in this database differ >> > from what keystone expects? What have you tried so far? >> > >> >> I am trying to figure out the best way of integrating keystone with 3rd >> party database. I have been reading but I would like to get expert >> opinion on which is the best way of doing it. >> >> Regards, >> Noorul > > How obscure is this database? If it can integrate with SQLAlchemy then it's > going to be relatively trivial and BY FAR the best approach. >
That database is accessible only using APIs. We have APIs to authenticate users against this DB, read projects to which user has access to, and roles to which user belongs to. > If that's not going to work then your only other option is to implement the > database as its own backend for each of the managers. If you look through > the folders in keystone (identity, credentials etc) you'll see a Driver class > for most of them that you will have to implement for your database. There > are examples of the sqlalchemy (and some LDAP) backends there that you can > work from. > I will look at LDAP back-end code. > I'd try to avoid the second case if you can avoid it. We've gotten better at > keeping the driver interface stable but you're going to have a constant > battle keeping interfaces and functionality up to date with the keystone > code. > So, if I understand correctly, in any case we need to modify keystone code. Thank you for the explanation. Regards, Noorul >> >> > >> >> >> >> I have been reading >> >> https://wiki.openstack.org/wiki/Keystone/Federation/Blueprint but I >> >> could not find a open reference implementation for the same. >> >> >> >> Regards, >> >> Noorul >> >> >> >> _______________________________________________ >> >> OpenStack-dev mailing list >> >> OpenStack-dev@lists.openstack.org >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> > _______________________________________________ >> > OpenStack-dev mailing list >> > OpenStack-dev@lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
