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