[Pulp-dev] Pulp3 Applicability Design thoughts (and Katello)

David Davis daviddavis at redhat.com
Fri Jan 17 15:16:01 UTC 2020


Neal,

Thanks for the feedback. Any idea if Cobbler or Pulp users would be
interested in applicability[0] being part of Pulp 3? One of the big changes
in Pulp 3 is that Pulp no longer maintains content consumer information so
we're debating about also dropping applicability from Pulp as well.

[0] https://hackmd.io/ydvHuzXNRA6T9eXx6cqy5A#Executive-Summary

David


On Fri, Jan 17, 2020 at 9:05 AM Neal Gompa <ngompa13 at gmail.com> wrote:

> On Fri, Jan 17, 2020 at 8:31 AM Justin Sherrill <jsherril at redhat.com>
> wrote:
> >
> > There have been some design discussions going on around applicability
> > (https://hackmd.io/ydvHuzXNRA6T9eXx6cqy5A) in pulp3.
> >
> > There are some big changes compared to pulp2, including:
> >
> > * Package profile, module profile,and repository list have to be
> > uploaded on every applicability computation
> >
> > * Calls for applicability are not asynchronous (which makes sense as
> > they are one profile at a time).
> >
> > Also keep in mind that due to the complexity of all the information
> > needed, Katello has been the primary (and sometimes the only?) user of
> > the service.
> >
> > For an example of what this might looks like, consider a repository that
> > syncs some new packages.  For 10,000 clients, it has to send the full
> > package profiles for all 10,000 clients, as well as the other
> > information in 10,000 api calls.  In Addition our task workers will have
> > to wait around for all 10,000 clients to be calculated.  One last point
> > is that katello already knows all the NVREA's for the rpms, which rpms
> > are in which repositories, which artifacts are in which modules, and
> > which packages are in what errata.
> >
> > Given all this, does it make sense for pulp to calculate the
> > applicability?  Or does it make sense for katello to?
> >
> > This assumes that no one else wants to use applicability in pulp3 (and
> > given the barrier to entry is even higher than it was in pulp2, that may
> > be possible).
> >
>
> The Cobbler team is interested in integrating with Pulp 3, though no
> investigation or work on this has started yet. I've also had a couple
> of conversations about it with the Uyuni developers, too. The biggest
> hangup previously for integrating Pulp into other tools is the MongoDB
> dependency that nobody wanted to deal with. Now that is gone, it has
> started looking interesting to people again.
>
> This is also part of the reason why I'd like to see the Pulp 3 stack
> shipped in Fedora. It would make it much easier for people to use it
> and explore integrating their infrastructure with it.
>
>
>
>
> --
> 真実はいつも一つ!/ Always, there's only one truth!
>
>
> _______________________________________________
> 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/20200117/20e2b22f/attachment.htm>


More information about the Pulp-dev mailing list