[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