[Pulp-list] Scheduled repo sync

[Jason Dobies]

-----BEGIN PGP SIGNED MESSAGE-----
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
handled.

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJMFmWlAAoJEOMmcTqOSQHCP9UH/RkPJS+C9hh55+3flRgkPpwy
gR6Hdmopfm/BjCxSu0TXRGfI8oC68MlBNS/LEoaf67pdp1wZjMcgyXWhP4PQMbT0
lSqaZEOU+TQbKAdGwA93BEcIUxKr7zZeRpkMMYCTCLl8dx0747C3Ipo7fLVz0ytr
NJcT9vZZ+k6BSzpbktziK1T8UimY/71tOUfzrgGD+9aF1RofZJ2PhlMiKmA+FMYY
YO73/15QA1IfSZ0fhR73K8pjYQy8Qa/O1eeEP+giAYuT739It1Zk1f3bgIe6BCLf
UFjoKcMFRcPLj2p6jEnMz0IrnKfmVkX2GJbmwSc8ho2yV6wZOYVBI7ORwvc7U6s=
=R1eE
-----END PGP SIGNATURE-----