On Fri, Jan 17, 2020 at 8:31 AM Justin Sherrill <jsher...@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? > > It does not make sense for Pulp 3 to calculate applicability. > 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). > People want it, but applicability calculation without any notion of registered clients simply falls outside of Pulp's domain. > > Justin > > > _______________________________________________ > 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
