Pulp

Will this support performing a GET on a particular publication? Could you explain what you mean by "Inspect what got published" ?

What API endpoint will be used to DELETE "All publications not referenced by a Distribution."?

I think the scope of this work should be limited to just being able to retrieve a particular publication, list all publications for a publisher, delete a particular publication.

dkliban@redhat.com wrote:

What API endpoint will be used to DELETE "All publications not referenced by a Distribution."?

Publications will need regular purging that thought that something like /publisher/xx/publication?distribution_id=NULL would be useful.

I think the scope of this work should be limited to just being able to retrieve a particular publication, list all publications for a publisher, delete a particular publication.

This would certainly be the minimum to support the use case but seems unnecessarily unhelpful.

This should be consistent with the approach taken for orphaned content and artifact purging. Do you know how deleting those orphans is currently supported?

I think the scope of this work should be limited to just being able to retrieve a particular publication, list all publications for a publisher, delete a particular publication.

This would certainly be the minimum to support the use case but seems unnecessarily unhelpful.

This should be consistent with the approach taken for orphaned content and artifact purging. Do you know how deleting those orphans is currently supported?

I don't think we currently support purging orphaned content or artifacts. That's one of the reasons I am hesitant to include this purge functionality as part of this story.

A user will need to be able to see what publications exist for a publisher, uniquely identify each by URL (for reference when creating or updating a Distribution for example), and delete unwanted publications.

I like the idea of setting on_delete=PROTECT for the distributor's FK to a publication. That would make it simple for a client to delete publications with simplicity, not having to worry about a race condition with updating a distributor.

If we enable individual deletion of publications in that way, I think bulk deletion could reasonably start as a client-side activity.

Server-side bulk deletion could be done multiple ways, and I think that's worth addressing independently. A key question I think of is: how many publications can reasonably be deleted while waiting for an HTTP response? Should we decide that if a single action is deleting more than 1 publication, that should be a task? That decision aside, we could have a task that does bulk deletion either for a single publisher or at some wider scope. Or we could have a publisher setting for how many old publications to keep, and let it just delete old ones as it makes new ones. And there are probably other options worth considering.

A publication representation should include the created timestamp, a reference to the publisher, and references to any distributions that reference it. Eventually we'll want to add the ability to see what content is published, presumably via a reference to a repo version. Taking that reference from two publications should also allow use of a comparison feature to see what changed between the two versions, and thus what content is different in the two publications. A repo version reference will also enable incremental publishes.

We'll also likely want to expose the artifacts and metadata at some point, but I can't think of a specific use case that's worth prioritizing right now.

What will the "natural key" be for a publication? Or in other words, what will come in the path after "<publisher>/publications/" ?

I'm fine with this task being only about listing and deleting single (specific) publications so long was we all agree that we need to consider supporting DEL at the REST collection level for orphans at some point:

• content
• artifact
• publication

Multiple deletes as a single DB operation will be fast and free of race conditions. I don't see how this should require tasking anything extraordinary in ViewSets.

As for the publication natural key .. there isn't one currently and can't think of anything that makes sense? You? It may need to be .../publishers/<id>/publications/<id>/

Seems reasonable. You may be right that bulk deletes of publications, particularly if limited to a single publisher, could run as a single fast operation if that's all it does. So maybe that would not need to be in a task.

Artifacts could be more interesting if files on disk have to be deleted as well.

Publications can have associated metadata files on disk so should probably implement the same as artifacts.

I updated the description to reflect the following decisions made on @pulp-dev:

• A POST to /publications/ will create a publishing task which replaces publisher/<id>/publish/
• In the future, one-time publisher options will be passed in the POST document and stored on the Publication as something generic like key-value pair.
• The created publication will be stored in a new Task.created_resources.
• Only successful publishing tasks will result in a Publication being stored in the DB and listed in Task.created_resources.