[Pulp-dev] Content types which are not compatible with the normal pulp workflow
jortel at redhat.com
Thu May 24 17:33:38 UTC 2018
On 05/17/2018 07:46 AM, Daniel Alley wrote:
> 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?
> 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?
I think OSTree and Ansible plugins will be in the same boat as Cargo.
In the case of OSTree, libostree does the heavy lifting for sync and
publishing and I suspect the same is true for Git based repositories.
We should consider way to best support distributing (serving) content in
core for these content types. I suspect this will mainly entail
something in the content app and perhaps a new component of a
Publication like PublishedDirectory that references an OSTree/Git
repository created in /var/lib/pulp/published. This may benefit Maven
> 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.
> Pulp-dev mailing list
> Pulp-dev at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev