[Pulp-dev] Content types which are not compatible with the normal pulp workflow

[Daniel Alley]

Some content types are not going to be compatible with the normal
sync/publish/distribute Pulp workflows, and will need to be live API-only.
To what degree should Pulp accomodate these use cases?

Example:

Pulp makes the assumptions that

A) the metadata for a repository can be generated in its entirety by the
known set of content in a RepositoryVersion, and

B) the client wouldn't care if you point it at an older version of the same
repository.

Cargo, the package manager for the Rust programming language, expects the
registry url to be a git repository.  When a user does a "cargo update",
cargo essentially does a "git pull" to update a local copy of the registry.

Both of those assumptions are false in this case. You cannot generate the
git history just from the set of content, and you cannot "roll back" the
state of the repository without either breaking it for clients, or adding
new commits on top.

A theoretical Pulp plugin that worked with Cargo would need to ignore
almost all of the existing Pulp primitives and very little (if any) of the
normal Pulp workflow could be used.

Should Pulp attempt to cater to plugins like these?  What could Pulp do to
provide a benefit for such plugins over writing something from scratch from
the ground up?  To what extent would such plugins be able to integrate with
the rest of Pulp, if at all?

We don't have to commit to anything pre-GA but it is a good thing to keep
in mind.  I'm sure there are other content types out there (not just Cargo)
which would face similar problems.  pulp_git was inquired about a few
months ago, it seems like it would share a few of them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180517/8060d6fb/attachment.htm>