RFC Feature Planning: User Groups

Imre Farkas ifarkas at redhat.com
Tue Apr 3 11:50:00 UTC 2012


On 03/30/2012 03:50 PM, Scott Seago wrote:
> Rather than paste in the entire text, I'm just linking to the wiki
> writeup. Please read the whole thing first and if you want to comment on
> anything specific, quote it and comment on this thread.
>
>
> https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Adding_User_Groups
>
>
> Scott
>


> In order not to tie conductor to LDAP for all installations, it should be a site-wide configuration whether groups come from LDAP or not. We'll need the conductor UserGroup/membership model anyway for joins in permission queries, so this configuration will simply determine how the group membership is maintained -- via LDAP hooks or via UI actions.
Is there any reason why we do not want to support both cases at the same 
time? Probably it would be a better user experience to let the user have 
both and indicate the source of a given group in the UI. If we define 2 
different scopes on UserGroup (user_defined, ldap_imported), it won't be 
much pain to handle both of them.

> There are a couple of options available for keeping the UserGroups in sync with LDAP groups:
> * Use delayed_job, cron, or something similar to re-sync on a specified schedule
> * Sync on use (with a pre-defined "minimum time between re-sync calls")
I would suggest a third approach: there could be some kind of auto 
re-sync mechanism, and the user would also have to option to request an 
update if he doesn't want to wait for the autoupdate to be called.

> The main advantages of sync-on-use are that 1) we make the minimum number of re-sync calls that still guarantees the data is fresh and 2) we don't require any external scheduling infrastructure. The main disadvantage is that the first permissions check after an idle period greater than the refresh interval (or one check per interval period if the server is under active use) will take longer than usual to return, as it has to wait for the LDAP group membership queries, any necessary writes for data changes, and the permission denormalization hooks for any changes to cascade down the object inheritance hierarchy. If this takes a long time with large datasets (many instances, images, users, etc), this will impact performance in a user-visible way.
To eliminate the downside of updating on user input, we could use 
delayed_job for that, too: instead of re-syncing with the ldap server 
during the request, we could just create a delayed_job task for that, 
inform the user that the background job has been created through a flash 
notice, and wait for the next available worker to pick up the task and 
do the autoupdate asynchronously.

Imre



More information about the aeolus-devel mailing list