RFC feature planning - robust instance launching

Scott Seago sseago at redhat.com
Fri Mar 30 13:45:49 UTC 2012


On 03/30/2012 06:29 AM, Angus Thomas wrote:
> On 03/30/2012 09:25 AM, Jan Provazník wrote:
>>
>> This means that we can't show a user any progress on above tasks and 
>> he will see only "loading page" cursor until it's finished. If we 
>> want to make UI not-blocked by above tasks and show users progress on 
>> them, it means doing this tasks on background. This means using some 
>> background solution - delayed_job or similar (but not condor please) 
>> or extending dbomatic significantly. I suggested using some 
>> background solution for launching instances many times but never got 
>> positive response.
>>
>> Taking advantage of the situation: is it a good idea to integrate 
>> background solution for launching instances at this moment and as a 
>> part of this scenario?
>
> Hi Jan
>
> I think you're right. We should be looking to get a delayed job 
> mechanism integrated as soon as we can. In addition to this case, 
> there are others which have come up recently, and which seem to 
> require a delayed job utility, including:
>
> - Syncing changes from LDAP periodically, which Scott is currently 
> planning.
> - Adding support for a single "build and push" operation in the UI
>
If it gets integrated anyway, I may use it for LDAP group 
synchronization. However, it may not be required (see the forthcoming 
mail on User Groups). Jay and I had an alternate idea on the Groups 
synchronization. Since we only need updated groups when we're actively 
performing a permissions check (or looking at the Groups or Permissions 
UI -- which already require permissions checks anyway), we can store the 
"last sync time" every time we re-sync Groups from LDAP. Every time we 
perform a permissions check, we check the "last sync time" and if Groups 
are stale, we re-sync in the foreground and then return the value of the 
permissions check. This will result in an occasional (hopefully small) 
delay in a page load when re-syncing groups, but it avoids unnecessary 
polling. If group-loading delays are too great, we can revert to the 
delayed_job approach (although for group syncing a cron job will work 
just as well)

Scott

>
> Angus




More information about the aeolus-devel mailing list