[Pulp-list] schedule sub-collections

Jason Connor jconnor at redhat.com
Tue Sep 11 16:55:22 UTC 2012


On Sep 11, 2012, at 7:24 AM, Jeff Ortel <jortel at redhat.com> wrote:

> I agree, part.  The unit_* seems odd.  But having the action in body instead of the URL seems ... un-RESTful.  I prefer something along the lines of Nick's suggestion:
> 
> /v2/consumers/<consumer id>/schedules/content/install/
> /v2/consumers/<consumer id>/schedules/content/update/
> /v2/consumers/<consumer id>/schedules/content/uninstall/
> 
> This approach is also consistent with existing non-scheduled content installs:
> 
> /v2/consumers/<consumer id>/actions/content/install/
> /v2/consumers/<consumer id>/actions/content/update/
> /v2/consumers/<consumer id>/actions/content/uninstall/


This has been my favorite suggestion so far as well, especially for the consumers. 

I'm still leaning toward my changes for the repositories schedules of:

/v2/repositories/<repo id>/importers/<importer id>/schedules/sync/
/v2/repositories/<repo id>/distributors/<distributor id>/schedules/publish/

They are, as Nick pointed out, very long. But the schedules here really do belong to both the repository and importer or distributor. The length is a side-effect of Pulp's plugin architecture, and, imho, not too much more overly obnoxious than REST in general.

Jason L Connor
linear on freenode #pulp
http://pulpproject.org/
RHCE: 805010912355231
GPG Fingerprint: 2048R/CC4ED7C1







More information about the Pulp-list mailing list