9:23 a.m.
On 19.9.2013 13:51, Bill Burke wrote:
On 9/19/2013 4:28 AM, Marek Posolda wrote:
> On 19.9.2013 03:11, Bill Burke wrote:
>> We need to decide what we want to do for M1. Here's my stab at it.
>> Let's discuss in email first as much as we can and then have a hangout
>> sometime next week to go over it and nail things down.
>>
>> First and foremost. We have to focus. No new features. No playing
>> around. For example: no adding refresh token support. No client-cert
>> support. No changes to protocols. No new backends. Let's just use
>> Picketlink JDBC. No 'forgot password' using SMS, etc... You get the
>> picture.
> At this moment, I have working MongoDB backend and I would like to send
> PR with it by the end of this week. I just need to adapt this with
> latest changes in RealmModel and UserModel interfaces (added new fields
> related to requiredActions and totp).
>
> TBH I don't know why to not have it as part of M1? I am not seeing any
> disadvantages for people to have possibility to choose from more
> backends?
Of course there is an advantage to Mongo et. al.! but there's a lot of
work to do just to get a usable milestone release. We just have to
focus on a minimal feature set to get the core done and playable to
the outside world.
Once we decide on our feature set for M1, you could help where needed,
or you could just continue improving/expanding back-end support.
Maybe moving to Mongo would be the way to go anyways considering the
performance considerations? I need your input here.
Thing is that I have it quite
done already (without adapting latest
model changes made by Stian to have support for required actions). So
ATM it's not much work with having it to push into milestone release.
Right now, The switch of Picketlink vs. Mongo back-end is done with
System properties. I am using those:
-Dkeycloak.sessionFactory=mongo will enable MongoDB store instead of
Picketlink store (Default value of this property is "picketlink", so
Picketlink it's still used by default)
All next properties are used just in case that Mongo is used as back-end
-Dkeycloak.mongodb.host=localhost -- host where MongoDB is running
-Dkeycloak.mongodb.port=27017 -- port where MongoDB is running
-Dkeycloak.mongodb.dropDatabaseOnStartup=true -- whether to clean DB at
startup or not
One of the advantages of Picketlink+JPA is, that users don't need to
setup DB as it's using in-memory H2 by default. However this could be
achieved with Mongo as well. It's possible to add another system
property, which could be used to start embedded instance of MongoDB
(Embedded MongoDB is something I am already using in unit tests)
Regarding performance, I made some performance tests in JMeter and I did
some comparison of Picketlink+MySQL vs. MongoDB. Results are much better
for Mongo and I think that it could be tuned even more. I sent another
email to keycloak-dev together with details and some charts in thread
"Performance test"
> Another thing is that it is easier for people to see or edit
> DB content directly in MongoDB database. Of course it's not so easy as
> directly edit XML/JSON file, but much easier than Picketlink IDM DB
> schema, which is quite complex.
>
> I am seeing just one disadvantage that every change in model interfaces
> needs to be adapted to both backend implementations, but you can always
> workaround this by implement stuff just for Picketlink and create JIRA
> for me to adapt changes to MongoDB backend. I can also disable MongoDB
> unit tests by default (ATM I have them enabled by default in my branch)
>
You might want to keep your backend in sync with master as I'll be
needing to add features to the backend to support the management UI.
yep, I will.
So the question is which way to choose?:
1) Merge Mongo implementation to master as soon as possible and if model
changes are needed, you will just create JIRA for me and I will always
adapt it
2) Don't merge right now and wait until model will be kind of final
I think 1 is better, so others could try it soon. WDYT?
Marek
Bill