<div dir="ltr"><div>tl;dr: at least for the initial Katello and Pulp3 integration, moving applicability to Katello I think is the best outcome for both communities.<br></div><div><br></div><div>What I'm reading (correct me if not accurate) is that Katello's calls to Pulp for applicability calculation need to flow so much data that Pulp's value to provide that applicability "answer" is not worth it. This is a concern for both performance and also integration complexity. If this is accurate, then I am +1 to have Katello handle the last call along with all the other data Katello indexes today. This would remove applicability from Pulp entirely.<br></div><div><br></div><div>In terms of Pulp wanting to offer applicability to its own users, I agree w/ @mhrivnak that since pulp3 is not "consumer-aware" that would be a large change at least. It would require significant planning to go after a feature set like that because Pulp3 would have to become consumer-aware again.<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 17, 2020 at 3:22 PM Michael Hrivnak <<a href="mailto:mhrivnak@redhat.com">mhrivnak@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">A little context from the past may help, though I'm not in-the-loop on recent planning (for a broad definition of "recent" ;) ).<div><br></div><div>Applicability was added to pulp at a time when pulp-agent existed, a process that ran on every managed host to both watch what packages were installed and carry out install/update/remove actions as directed. Pulp-agent was deprecated and removed long ago based on broad agreement that there are better tools for managing what's installed on each host, and that it made more sense to focus on utilizing those. During the time when pulp-agent existed, pulp owned both the repo data and consumer data, so it made sense for pulp to do applicability calculations.</div><div><br></div><div>As already mentioned, pulp 3 is not "consumer-aware". That was a deliberate choice, and applicability was expected back then to be implemented as a separate service. There are potentially many additional advantages to having it separate, such as scaling independently, deploying it only for those who want it, using a technology stack best-suited to the job (graph DB? different language? dedicated cache? closely-utilize dnf's own code?), etc.</div><div><br></div><div>One of the major disadvantages of pulp 2's applicability features is that it re-implements the decision-making that takes place on a host as calculated by yum or dnf (you basically want the output of `dnf check-update`), and it's hard to produce exactly the same results. It could be amazing if applicability calculation re-used the same code as dnf, but that kind of tight integration is easier done as a separate code base.</div><div><br></div><div>Another disadvantage in pulp 2 is that it was hard to know if there was a difference between the content in the repo vs. what was currently published and visible to the consumers. Pulp 3's repo versions and publications will make that a non-issue and open up much easier opportunities for caching applicability results.</div><div><br></div><div>I'm sure some assumptions and requirements have changed since we originally established the fundamentals of pulp 3, but hopefully it's useful to have a little encouragement from the past that keeping applicability separate was at that point considered both reasonable and desirable. In any case, it will be exciting to see what you all come up with.</div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr"><br></div></div>-- <br><div dir="ltr"><div dir="ltr"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px;padding:0px"><span style="margin:0px;padding:0px">Michael</span> <span style="margin:0px;padding:0px">Hrivnak</span></p><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px;padding:0px"></p><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px;padding:0px"><span style="margin:0px;padding:0px">Principal Software Engineer</span><span style="margin:0px;padding:0px">, <span style="margin:0px;padding:0px">RHCE</span></span> </span><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px"></span><br style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px;padding:0px"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px;padding:0px">Red Hat</p></div></div></div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div>