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

[Jeff Ortel]

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?
>
> 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?

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 
as well.

>
> 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
> https://www.redhat.com/mailman/listinfo/pulp-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180524/8c510304/attachment.htm>