<div dir="ltr"><div>I think Pulp does have enough value proposition over a script-based alternative to make it worthwile for all of those types of plugins. Here are a few points I think about:</div><div><br></div><div>* scalability. A common story users tell is that scripts work well up until a point. Doing it for an entire organization, or when content comes from many places, or with more than a few people involved in maintaining the content, it becomes unmaintainable.</div><div><br></div><div>* Stacks of content. Often a group of content goes together, but each piece of content is updated separately. For instance with Ansible roles, you may use many of them together to deploy something, but each role may receive changes separately. I think of all this content together as a "stack". Keeping everything up to date can be challenging. Managing that change with scripts can be hard and fragile. Also the ability to rollback quickly an confidently is something Pulp can offer.</div><div><br></div><div>* Organizing content is easier. Having an API that you can use to organize content is easier than doing lots and lots of git yourself or with scripts.<br></div><div><br></div><div>* Tasking. Long running tasks (and a lot of them) can be unweildy, and Pulp makes that very organized and run very well.</div><div><br></div><div>* Static and vulnerability analysis. We're seeing interest in
using analysis projects like Clair (<a href="https://github.com/arminc/clair-scanner">https://github.com/arminc/clair-scanner</a>) to scan
content in Pulp. By bringing all the content into one place, and
that place having a tasking system that plugin writers can control how their content can be analyzed continuously.</div><div><br></div><div>Also +1 to jortel's idea. I think that's a great idea and exactly what we need.<br></div><div><br></div><div><div><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 24, 2018 at 1:33 PM, Jeff Ortel <span dir="ltr"><<a href="mailto:jortel@redhat.com" target="_blank">jortel@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"><span class="gmail-">
<br>
<br>
<div class="gmail-m_-688849407322133567moz-cite-prefix">On 05/17/2018 07:46 AM, Daniel Alley
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>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?<br>
</div>
<div><br>
</div>
<div>Example: <br>
</div>
<div><br>
</div>
<div>Pulp makes the assumptions that <br>
</div>
<div><br>
</div>
<div>A) the metadata for a repository can be generated in its
entirety by the known set of content in a RepositoryVersion,
and</div>
<div><br>
</div>
<div>B) the client wouldn't care if you point it at an older
version of the same repository. <br>
</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>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?</div>
</div>
</blockquote>
<br></span>
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.<br></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
<br>
<blockquote type="cite"><span class="gmail-">
<div dir="ltr">
<div><br>
</div>
<div>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.</div>
</div>
<br>
<fieldset class="gmail-m_-688849407322133567mimeAttachmentHeader"></fieldset>
<br>
</span><pre>______________________________<wbr>_________________
Pulp-dev mailing list
<a class="gmail-m_-688849407322133567moz-txt-link-abbreviated" href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a>
<a class="gmail-m_-688849407322133567moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/pulp-dev" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a>
</pre>
</blockquote>
<br>
</div>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div></div></div></div></div></div></div></div>