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@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev
_______________________________________________
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev
