Pulp: Issueshttps://pulp.plan.io/https://pulp.plan.io/favicon.ico2015-06-24T20:53:33ZPulp
Planio RPM Support - Issue #1088 (CLOSED - WONTFIX): Incremental publish could use the wrong primary.xml...https://pulp.plan.io/issues/10882015-06-24T20:53:33Zbcourtbcourt@redhat.com
<p>The incremental publish searches for the most recently modified file with a filename that matches a regex. It would be more robust to identify the file from the old repomd.xml instead of searching for one on the filesystem. For example, if there are two primary.xml files in the repodata directory, the incremental publish should use the one from the repodata.xml and not the first one it finds.</p>
<p>This regex is performed here[0].</p>
<p>[0]: <a href="https://github.com/pulp/pulp/blob/60d8aa1406703bb0f20d3632d0a8e2f5f48b66a6/server/pulp/plugins/util/metadata_writer.py#L325-L334" class="external">https://github.com/pulp/pulp/blob/60d8aa1406703bb0f20d3632d0a8e2f5f48b66a6/server/pulp/plugins/util/metadata_writer.py#L325-L334</a></p> RPM Support - Issue #1087 (CLOSED - CURRENTRELEASE): publishing of distribution units should igno...https://pulp.plan.io/issues/10872015-06-24T20:51:42Zbcourtbcourt@redhat.com
<p>Publishing of distribution units should ignore files in the repodata directory. This caused a corrupted publish where the distribution included a primary.xml and the incremental update picked the wrong file because there were two primary.xml files in the directory.</p> RPM Support - Issue #1086 (CLOSED - CURRENTRELEASE): pulp_distribution.xml sync should ignore rep...https://pulp.plan.io/issues/10862015-06-24T20:49:25Zbcourtbcourt@redhat.com
<p>Files that are synced via the pulp_distribution.xml file should ignore all files in the repodata/ directory of the repository.</p> RPM Support - Issue #1045 (CLOSED - DUPLICATE): incremental publish does not remove old updateinf...https://pulp.plan.io/issues/10452015-06-10T14:56:32Zbcourtbcourt@redhat.com
<p>When an incremental publish is performed the old updateinfo.xml is not removed if a checksum is specified. Each publish adds a new updateinfo, which has a different checksum.</p>
<p>After each publish there should be only one updateinfo.xml in the repodata directory.</p> RPM Support - Issue #1044 (CLOSED - WONTFIX): Yum distributor validation of relative url is match...https://pulp.plan.io/issues/10442015-06-10T13:02:50Zbcourtbcourt@redhat.com
<p>The validation of relative urls for the yum distributor is overly broad and is matching ISO repos as well as yum repos. This is causing problems because they are actually served from different paths and are causing false negatives from the validation: pulp_rpm/plugins/distributors/yum/configuration.py:456</p> RPM Support - Issue #1042 (CLOSED - CURRENTRELEASE): Exception raised when building error message...https://pulp.plan.io/issues/10422015-06-09T17:33:31Zbcourtbcourt@redhat.com
<p>If a repo is created using a relative_url</p>
<p>The line <a href="https://github.com/pulp/pulp_rpm/blob/pulp-rpm-2.6.1-1/plugins/pulp_rpm/plugins/distributors/yum/configuration.py#L469" class="external">https://github.com/pulp/pulp_rpm/blob/pulp-rpm-2.6.1-1/plugins/pulp_rpm/plugins/distributors/yum/configuration.py#L469</a><br>
is checking which will raise a KeyError if 'relative_url' has not been defined in the distributor config.</p>
<pre><code>conflicting_relative_url = distributor['config']['relative_url'] or conflicting_repo_id
</code></pre>
<p>This should be replaced with something like</p>
<pre><code>if 'relative_url' in distributor['config']:
conflicting_relative_url = distributor['config']['relative_url'] or conflicting_repo_id
else:
conflicting_relative_url = conflicting_repo_id
</code></pre> Docker Support - Refactor #1037 (CLOSED - CURRENTRELEASE): Remove manual setting for repo.repo_idhttps://pulp.plan.io/issues/10372015-06-05T19:34:46Zbcourtbcourt@redhat.com
<p>Remove manual setting of repo.repo_id = repo_transfer.id throughout Docker and OSTree plugins.</p>
<p>All other usages should already use repo_transfer.repo_obj to access the native object (with its id) from the repo_transfer object.</p> Pulp - Issue #993 (CLOSED - CURRENTRELEASE): Worker discovery takes 30 seconds when all services ...https://pulp.plan.io/issues/9932015-05-20T17:39:07Zbcourtbcourt@redhat.com
<p>When all of the pulp services are restarted at the same time it often takes 30 seconds before the workers are discovered.</p>
<p>When running the script:</p>
<pre><code>[root@bcourt pulp]# /home/bcourt/bin/restart-pulp.sh
++ systemctl stop httpd
++ systemctl stop pulp_workers
++ systemctl stop pulp_resource_manager
++ systemctl stop pulp_celerybeat
++ systemctl stop goferd
++ systemctl stop qpidd
++ systemctl start qpidd
++ systemctl start goferd
++ systemctl start pulp_celerybeat
++ systemctl start pulp_resource_manager
++ systemctl start pulp_workers
++ systemctl start httpd
[root@bcourt pulp]#
</code></pre>
<p>The following are the relevant log entries:</p>
<pre><code>May 20 13:33:42 bcourt.usersys.redhat.com pulp[8229]: pulp.server.webservices.application:INFO: *************************************************************
May 20 13:33:42 bcourt.usersys.redhat.com pulp[8229]: pulp.server.webservices.application:INFO: The Pulp server has been successfully initialized
May 20 13:33:42 bcourt.usersys.redhat.com pulp[8229]: pulp.server.webservices.application:INFO: *************************************************************
May 20 13:33:42 bcourt.usersys.redhat.com pulp[8229]: gofer.messaging.adapter.qpid.connection:INFO: opened: qpid+tcp://localhost:5672
May 20 13:33:42 bcourt.usersys.redhat.com pulp[8229]: gofer.messaging.adapter.connect:INFO: connected: qpid+tcp://localhost:5672
May 20 13:34:10 bcourt.usersys.redhat.com pulp[8185]: pulp.server.async.worker_watcher:INFO: New worker 'reserved_resource_worker-1@bcourt.usersys.redhat.com' discovered
May 20 13:34:10 bcourt.usersys.redhat.com pulp[8185]: pulp.server.async.worker_watcher:INFO: New worker 'reserved_resource_worker-3@bcourt.usersys.redhat.com' discovered
May 20 13:34:10 bcourt.usersys.redhat.com pulp[8185]: pulp.server.async.worker_watcher:INFO: New worker 'reserved_resource_worker-0@bcourt.usersys.redhat.com' discovered
May 20 13:34:11 bcourt.usersys.redhat.com pulp[8185]: pulp.server.async.worker_watcher:INFO: New worker 'reserved_resource_worker-2@bcourt.usersys.redhat.com' discovered
</code></pre>
<p>This looks like a race condition where the initial heartbeat from the worker is missed as celerybeat is still starting up. A simple solution would be to have the workers heartbeat faster initially and then back off once they have communication with celerybeat.</p> RPM Support - Issue #951 (CLOSED - CURRENTRELEASE): checksum is not honored if sqlite generation ...https://pulp.plan.io/issues/9512015-05-05T18:51:45Zbcourtbcourt@redhat.com
<p>If sqlite generation is enabled the checksum is always using sha256</p> Pulp - Issue #947 (CLOSED - CURRENTRELEASE): Error string is missing string identiferhttps://pulp.plan.io/issues/9472015-05-04T20:15:52Zbcourtbcourt@redhat.com
<p>the s is missing from a "%()s" identifier for string substitution on error PLP0008. This should never be hit at runtime as this error is mostly for debug purposes</p> Pulp - Refactor #867 (CLOSED - WONTFIX): Update the docs for the Plugin API to use the MongoEngin...https://pulp.plan.io/issues/8672015-04-10T15:56:47Zbcourtbcourt@redhat.com
<p>Deliverables:</p>
<ul>
<li>Updated documentation on how to use the MongoEngine unit & repository models for plugin development</li>
<li>Release notes on the deprecation of the conduits in favor of the unit models</li>
</ul> Packaging - Issue #724 (CLOSED - CURRENTRELEASE): Integration test runner fails because it can't ...https://pulp.plan.io/issues/7242015-03-04T16:38:19Zbcourtbcourt@redhat.com
<p>The Jenkins job to run the integration tests against a given repository is currently broken due to a problem selecting the appropriate image to use in the qeos environment. The get_pulp_images() in the os1 utils script should be updated to use the image name rather than a tag.</p>
<p><a href="https://github.com/pulp/pulp_packaging/blob/master/ci/deploy/utils/os1_utils.py#L100" class="external">https://github.com/pulp/pulp_packaging/blob/master/ci/deploy/utils/os1_utils.py#L100</a></p> Pulp - Issue #682 (CLOSED - CURRENTRELEASE): publish_repo failures that do not raise an exception...https://pulp.plan.io/issues/6822015-02-28T23:22:14Zbcourtbcourt@redhat.com
<p>Description of problem:</p>
<p>When a distributor has it's publish_repo method called and the publish report return indicates a failure the task is marked as completing successfully. If the publish_repo method raises an exception the task is marked properly as failed.</p>
<p>+ This bug was cloned from <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1186920" class="external">Bugzilla Bug #1186920</a> +</p> Pulp - Issue #640 (CLOSED - CURRENTRELEASE): Current master of nectar requires a newer version of...https://pulp.plan.io/issues/6402015-02-28T22:46:43Zbcourtbcourt@redhat.com
<p>Description:<br>
The current master branch of nectar will fail if run against python-requests 2.2.1. The dependency in pulp & nectar should be updated or the threaded downloader should be updated to not use the new python-requests api.</p>
<p>+ This bug was cloned from <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1174283" class="external">Bugzilla Bug #1174283</a> +</p> Pulp - Issue #489 (MODIFIED): When an task worker dies or restarts, work assigned to that worker ...https://pulp.plan.io/issues/4892015-02-28T22:15:18Zbcourtbcourt@redhat.com
<p>Description of problem:</p>
<p>When an RQ restarts (or dies) the tasks assigned to that worker get marked as cancelled. The cancelled state is correct, but users who dispatch work don't expect random cancelling of tasks so this isn't a great behavior.</p>
<p>To reproduce:<br>
1. Start Pulp system with exactly 1 worker<br>
2. Start a really long sync<br>
3. List the tasks and observe that the task you submitted is in the running state<br>
4. During the sync `kill -9` the worker<br>
5. Start that worker up again<br>
6. List the tasks again and observe that the task you submitted is in the cancelled state</p>
<p>Expected result: That the work you submitted to Pulp doesn't end up in the cancelled state when a worker dies. I expect it to be re-picked up by the worker and be in the running state.</p>