[Pulp-list] Scheduled repo sync

Jason Dobies jason.dobies at redhat.com
Mon Jun 14 17:23:49 UTC 2010

Hash: SHA1

> "* If a sync schedule already exists on a repo, the call to create a new
> schedule entry will fail. The user must explicitly remove the existing
> schedule prior to creating a new one. This should help minimize user
> errors where the incorrect repo ID is specified and prevent existing
> schedules from being destroyed."
> why the notion of 'add and delete' for schedules.  Why not just
> set/unset?  If you have only one schedule entry it seems like it is more
> of something that you would just set or clear.  Calling any CLI/API to
> set the schedule wouldn't error out if their schedule was there, it
> would just update the field.
> with the add/delete you need new API methods for setting schedules:
> repoApi.create_sync_schedule('some-id', '01 * * * *')
> *error*
> repoApi.delete_sync_schedule('some-id')
> repoApi.create_sync_schedule('some-id', '01 * * * *')
> vs just :
> repo = repoApi.repo('some-id')
> repo['syncSchedule'] = '01 * * * *'
> repoApi.update(repo)
> and to delete:
> repo = repoApi.repo('some-id')
> repo['syncSchedule'] = None
> repoApi.update(repo)
> Mike

Interesting, I hadn't thought of doing it as purely repo metadata.
That's how it was going to be stored in the database, but my initial
thoughts on how to set it were different.

Setting it on the repo object is simpler, but I'm not sure that makes it
better. It feels like there's something more to automated
synchronization than just a quick metadata flag, so I feel like the API
should convey that you're making a non-trivial change to how the repo is

I suppose I'm going to have to handle the direct repo object update case
in either solution, since even if there are separate APIs that still
won't prevent the caller from changing the schedule from the repo object
directly. If that's the case, adding in the add/delete methods is
syntactic sugar, which brings us to the question of whether or not we
want to support that sort of flexibility.

Ok, I kinda talked myself in a circle. Since it's shorter
implementation-wise to hang it off of update, I'll start with that and
see how it looks.

- -- 
Jason Dobies
RHCE# 805008743336126
Freenode: jdob
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/


More information about the Pulp-list mailing list