Pulp: Issueshttps://pulp.plan.io/https://pulp.plan.io/favicon.ico2017-11-16T14:47:41ZPulp
Planio Pulp - Issue #3140 (CLOSED - DUPLICATE): pulp_streamer doesnt set HTTP response headers, causing ...https://pulp.plan.io/issues/31402017-11-16T14:47:41Zpmoravec@redhat.compmoravec@redhat.com
<p>When installing a package from a repository with on demand download policy, <code>squid</code> should cache the responses to 1) limit response times of further client requests, and 2) to save bandwidth between the pulp server and the upstream repo.</p>
<p>But <code>squid</code> does not cache the responses / RPMs sent by <code>pulp_streamer</code>, so any request from each and every client (re)fetching the package follows the full path <code>httpd-->squid-->pulp_streamer-->upstream-repo-->pulp_streamer-->squid-->httpd</code> again. Including <code>deferred_download</code> task as well.</p>
<p>The reason is <code>pulp_streamer</code> does not set <code>HTTP</code> response headers (<code>Last-Modified</code> and <code>Expires</code> required) required by <code>squid</code> to determine expiration of the cache entry.</p>
<p>Two possible resolutions are possible:</p>
<ul>
<li>
<code>pulp_streamer</code> will set the HTTP response headers accordingly,</li>
<li>or <code>squid</code> will be (recommended to be) configured to cache packages by default, using e.g.:</li>
</ul>
<pre><code>refresh_pattern .rpm$ 15 50% 4320
</code></pre>
<p>in `squid.conf`. Here I assume <code>deferred_download</code> task running every 10 minutes, so an rpm object dealt as fresh for 15 minutes is more than enough. (I am not sure what all unit types can be queried via <code>squid</code> so if the above rule covers everything)</p> RPM Support - Issue #3115 (CLOSED - CURRENTRELEASE): One sample request in API doc for regenerate...https://pulp.plan.io/issues/31152017-11-03T11:05:55Zpmoravec@redhat.compmoravec@redhat.com
<p>In <a href="https://docs.pulpproject.org/dev-guide/integration/rest-api/consumer/applicability.html" class="external">https://docs.pulpproject.org/dev-guide/integration/rest-api/consumer/applicability.html</a> , section "Generate Content Applicability for Updated Repositories", there is Sample request:</p>
<pre><code>{
"repo_criteria": {
"filters": {"id": {"$in": ["test-repo", "test-errata"]}},
"parallel": true
}
}
</code></pre>
<p>However "parallel" is not a part of "repo_criteria" but a parameter on the same level. That Sample request should be:</p>
<pre><code>{
"repo_criteria": {
"filters": {"id": {"$in": ["test-repo", "test-errata"]}},
},
"parallel": true
}
</code></pre> Pulp - Story #2125 (CLOSED - WONTFIX): make pulp regenerate applicability calculation incrementalhttps://pulp.plan.io/issues/21252016-08-03T07:45:51Zpmoravec@redhat.compmoravec@redhat.com
<p>Assume pulp has already synced a big repo with thousands of RPMs and hundreds of erratas. These have been already calculated in regenerate applicability.</p>
<p>Now, syncing a new content from an importer brings say tens RPMs and few errata. Regenerate applicability then recalculates whole repo content, mostly redundantly.</p>
<p>Since reg.app task can take hours, making it incremental can be substantial performance improvement. Please make the reg.app. calculation incremental for that.</p>