[Pulp-list] Task Scheduling Question

John Matthews jmatthew at redhat.com
Fri Apr 8 15:29:32 UTC 2011



----- Original Message -----
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Say I create a new repo A with an interval scheduler and a start time.
> If I'm understanding the implementation correctly, that means that at
> all times, there will be a task on the queue for "sync repo A" (either
> executing or the next scheduled run of it).
> 
> What happens if I go through pulp-admin and call repo sync on A? I
> suspect the task will fail to queue since it'll trip the uniqueness
> check.
> 
> If that's not the case, the rest of this email is invalid.

This is the intent, but there is a bug dgao/shughes found.  Through the CLI this works OK, through API it's busted and the uniqueness check fails.  I'm in the middle of fixing it now.


> 
> But if that's the case, I think we need a bit more refinement in this
> area. From what I remember, the repo sync API will just say whether or
> not the sync was added as a task, but not "why" it wasn't added. So in
> the CLI, I'm guessing we'll tell the user we can't schedule the sync
> cause it's already running (which was the previous motivation for the
> uniqueness check there), which isn't accurate. We'll need to
> distinguish
> between "the sync is currently running" and "the sync is scheduled to
> run again at XX:XX".
> 
> This also brings up a potential issue in that we can't manually
> trigger
> a repo sync if there's a schedule on the repo. So if you had a repo
> set
> to sync every, say 24 hours, but needed to run it immediately to pick
> up
> a fix, you can't.
> 
> Is that going to present an issue? I think that's a valid use case for
> wanting to have a scheduled sync but also the ability to kick it to
> sync
> immediately, but I'm curious what others think.
> 

Sounds like a valid use case.





More information about the Pulp-list mailing list