----- Original Message ----- > From: "Noorul Islam K M" <[email protected]> > To: "Jamie Lennox" <[email protected]> > Cc: "OpenStack Development Mailing List (not for usage questions)" > <[email protected]> > Sent: Friday, 7 February, 2014 7:13:20 PM > Subject: Re: [openstack-dev] [keystone] Integrating with 3rd party DB > > Jamie Lennox <[email protected]> writes: > > > ----- Original Message ----- > >> From: "Noorul Islam K M" <[email protected]> > >> To: "Dolph Mathews" <[email protected]> > >> Cc: "OpenStack Development Mailing List (not for usage questions)" > >> <[email protected]> > >> Sent: Friday, 7 February, 2014 2:00:34 PM > >> Subject: Re: [openstack-dev] [keystone] Integrating with 3rd party DB > >> > >> Dolph Mathews <[email protected]> writes: > >> > >> > On Thu, Feb 6, 2014 at 6:38 AM, Noorul Islam Kamal Malmiyoda < > >> > [email protected]> 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.
No, you can write the driver and then load it from outside of keystone via the config file. However you will need to closely look at the Driver calls within keystone, i'm pretty sure that these aren't documented anywhere. > 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 > >> >> [email protected] > >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> >> > >> > _______________________________________________ > >> > OpenStack-dev mailing list > >> > [email protected] > >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> _______________________________________________ > >> OpenStack-dev mailing list > >> [email protected] > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > > > _______________________________________________ > > OpenStack-dev mailing list > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
