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