Open Stack

Jamie Lennox <jamielennox at redhat.com> writes:

> ----- Original Message -----
>> From: "Noorul Islam K M" <noorul at noorul.com>
>> To: "Dolph Mathews" <dolph.mathews at gmail.com>
>> Cc: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at 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.mathews at gmail.com> writes:
>> 
>> > On Thu, Feb 6, 2014 at 6:38 AM, Noorul Islam Kamal Malmiyoda <
>> > noorul at 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 at lists.openstack.org
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> > _______________________________________________
>> > OpenStack-dev mailing list
>> > OpenStack-dev at lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev