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 <[email protected]> wrote: > On Fri, Jan 17, 2020 at 8:31 AM Justin Sherrill <[email protected]> > 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 > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-dev >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
