I like the idea of applicability not being in pulp. It makes it a cleaner solution if pulp "just" does repo management.
-- bk On 1/17/20 8:30 AM, Justin Sherrill 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). > > Justin > > > _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
