<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>To wrap this discussion up, it seems that there is pretty wide
      agreement that this functionality best fits into Katello.</p>
    <p>We'll likely start an RFC discussion over at the foreman <a
        href="https://community.theforeman.org/" moz-do-not-send="true">Discourse</a>
      server soon: <a class="moz-txt-link-freetext" href="https://community.theforeman.org/">https://community.theforeman.org/</a>.<br>
    </p>
    <p>Thanks All!<br>
    </p>
    <p>Justin<br>
    </p>
    <div class="moz-cite-prefix">On 1/17/20 8:30 AM, Justin Sherrill
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:5ed1b613-84f9-c9a9-5555-53b4faa9ccd4@redhat.com">There
      have been some design discussions going on around applicability
      (<a class="moz-txt-link-freetext" href="https://hackmd.io/ydvHuzXNRA6T9eXx6cqy5A">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
      uploaded on every applicability computation
      <br>
      <br>
      * Calls for applicability are not asynchronous (which makes sense
      as they are one profile at a time).
      <br>
      <br>
      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.
      <br>
      <br>
      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.
      <br>
      <br>
      Given all this, does it make sense for pulp to calculate the
      applicability?  Or does it make sense for katello to?
      <br>
      <br>
      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).
      <br>
      <br>
      Justin
      <br>
      <br>
    </blockquote>
  </body>
</html>