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 - Refactor #1056 (CLOSED - WONTFIX): Restructure distribution units to allow deprecat...https://pulp.plan.io/issues/10562015-06-15T13:39:27Zbcourtbcourt@redhat.com
<p>Currently distribution units keep a "files" attribute that lists each file that is part of the distribution. This should be changed to allow the contents of the distribution unit to be overlaid on top of the repository without needing to list every file.</p>
<p>1) The (treeinfo/.treeinfo) file is renamed to "treeinfo" during the sync.<br>
2) The existence of the treeinfo file is indicated on the unit object<br>
3) During publish time the contents of the distribution are overlaid on the repository being generated.<br>
4) The files attribute can be deprecated/removed</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> Pulp - Story #1029 (CLOSED - WONTFIX): Automatically verify release note existence in the test ru...https://pulp.plan.io/issues/10292015-06-04T13:49:06Zbcourtbcourt@redhat.com
<p>In pulp/devel/test_runner.py optionally verify the standard release notes exist for the version specified in a project spec file.</p>
<p>Each project would provide an optional release_notes_dir argument when they call pulp/devel/test_runner.py. If this is specified then<br>
1) Get the current version being built from the spec file in the project root<br>
2) Validate that a <release_notes_dir>/<major>.<minor>.x.rst file exists<br>
3) Validate that the major.minor.version number exists in the rst file</p> Pulp - Refactor #994 (CLOSED - WONTFIX): Repository content_unit counts should be calculated usin...https://pulp.plan.io/issues/9942015-05-20T21:09:51Zbcourtbcourt@redhat.com
<p>Currently the unit counts on repositories is calculated by atomically adding or subtracting values from the current value. Pulp should let mongo calculate these values for us using an aggregation query:<br>
db.repo_content_units.aggregate({'$match':{'repo_id': '<repo_id>'}}, {'$group': {'_id':'$unit_type_id','sum' :{'$sum':1}}})</p>
<p>With some general testing this query took 0.12 seconds on a repository with 11k total packages (3k erratum and 8k rpm)</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> Python Support - Refactor #877 (CLOSED - CURRENTRELEASE): convert pulp_python to use MongoEngine ...https://pulp.plan.io/issues/8772015-04-10T17:34:02Zbcourtbcourt@redhat.com
<p>Convert the pulp_python to use MongoEngine models for all unit actions instead of the associated unit</p>
<p>Deliverables:</p>
<ul>
<li>ContentUnit model for Package units
<ul>
<li>The model is registered via the entry point</li>
<li>The types .json file is removed, and references to it in the spec files are are also removed</li>
</ul>
</li>
<li>All interactions with units in the plugin use the new unit model and the Repository model for creating, saving and updating units</li>
<li>Convert the model according to the <a href="https://fedorahosted.org/pulp/wiki/ConvertingModelsToMongoengine#StepsinvolvedinconvertingaPulpmodeltoMongoEngine" class="external">conversion guide</a>
</li>
</ul> Puppet Support - Refactor #875 (CLOSED - CURRENTRELEASE): Convert pulp_puppet to use MongoEngine ...https://pulp.plan.io/issues/8752015-04-10T17:31:24Zbcourtbcourt@redhat.com
<p>Convert the pulp_puppet to use MongoEngine models for all unit actions instead of the associated unit</p>
<p>Deliverables:</p>
<ul>
<li>ContentUnit model for docker_image units
<ul>
<li>The model is registered via the entry point</li>
<li>The types .json file is removed, and references to it in the spec files are are also removed</li>
</ul>
</li>
<li>All interactions with units in the plugin use the new unit model and the Repository model for creating, saving and updating units</li>
</ul> RPM Support - Refactor #874 (CLOSED - CURRENTRELEASE): Convert pulp_rpm to use MongoEngine Modelshttps://pulp.plan.io/issues/8742015-04-10T17:30:25Zbcourtbcourt@redhat.com
<p>Convert the pulp_rpm to use MongoEngine models for all unit actions instead of the associated unit</p>
<p>Deliverables:</p>
<ul>
<li>ContentUnit model for docker_image units
<ul>
<li>The model is registered via the entry point</li>
<li>The types .json file is removed, and references to it in the spec files are are also removed</li>
</ul>
</li>
<li>All interactions with units in the plugin use the new unit model and the Repository model for creating, saving and updating units</li>
</ul> Puppet Support - Story #83 (CLOSED - CURRENTRELEASE): As a user I can install puppet modules usin...https://pulp.plan.io/issues/832014-12-19T21:40:05Zbcourtbcourt@redhat.com
<p>As a user I can install a module using the puppet module install command line using the v3 forge api enumerated at <a href="https://forgeapi.puppetlabs.com/" class="external">https://forgeapi.puppetlabs.com/</a></p>
<p>This will entail creating a new /v3/releases endpoint. We will have to go back to the pre-puppet 3.3 method of determining the repository and consumer as the ability to specify a context root has been disabled.</p>
<p>The api now requires pagination, offset tracking, and providing the urls for the next/previous queries in the case of pagination.<br>
There are now many more options for filtering.</p>
<p>We will only have to support the /v3/releases endpoint at this time.</p>