Pulp: Issueshttps://pulp.plan.io/https://pulp.plan.io/favicon.ico2021-04-14T01:04:12ZPulp
Planio RPM Support - Task #8555 (CLOSED - WORKSFORME): Verify that Pulp can handle mixed-checksum reposi...https://pulp.plan.io/issues/85552021-04-14T01:04:12Zdalleydalley@redhat.com
<p>"we should consider having Pulp be able to handle different checksum types."</p>
<p>See associated BZ for more details</p> RPM Support - Refactor #7883 (CLOSED - WORKSFORME): ConsumeSignedContent functional test should n...https://pulp.plan.io/issues/78832020-11-20T19:14:19Zdalleydalley@redhat.com
<p>This utility, used by some functional tests, opens a shell and imports pulpcore. If pulpcore is not available it blows up.</p> Pulp - Story #7545 (CLOSED - WORKSFORME): Pulp_installer : customize http port + number of workershttps://pulp.plan.io/issues/75452020-09-22T15:13:02Zswisscom
<p>Dear team,
Two improvement requests for the Ansible installer :</p>
<ul>
<li>For technical reasons I have to change the http port on Nginx. I see this parameter is not customizable (80 is hardcoded in the nginx.conf.j2 template). Currently I change it manually in nginx.conf after each pulp_installer run. Would it be possible to make the http port customizable in the playbook ?</li>
<li>Would it be possible to add a customizable variable to create more than 2 workers when running pulp_installer ?</li>
</ul>
<p>Thanks a lot</p> Pulp - Task #7229 (CLOSED - WORKSFORME): publish plugin documentation at docs.pulpproject.orghttps://pulp.plan.io/issues/72292020-07-28T17:45:50Zdkliban@redhat.com
<p>We currently host 'pulpcore' documentation at the root of docs.pulproject.org. We want to publish documentation for additional pulp plugins under that domain. We want each plugin to be stored in the directory corresponding to its name.</p>
<pre><code>docs.pulpproject.org/pulpcore/
docs.pulpproject.org/pulp_rpm/
docs.pulpproject.org/pulp_file/
docs.pulpproject.org/pulp_container/
docs.pulpproject.org/pulp_deb/
docs.pulpproject.org/pulp_gem/
docs.pulpproject.org/pulp_npm/
docs.pulpproject.org/pulp_maven/
docs.pulpproject.org/pulp_python/
docs.pulpproject.org/pulp_ansible/
</code></pre>
<p>The root of the domain should forward users to <code>docs.pulpproject.org/pulpcore/</code>.</p>
<p>Each plugin should use its own user (named the same as the directory). Each user should only have the ability to write to its plugin directory. Each plugin is going to use rsync (and a unique private key) to publish the documentation to its directory.</p> RPM Support - Story #6740 (CLOSED - WORKSFORME): As a user I can skip drpms during synchttps://pulp.plan.io/issues/67402020-05-14T15:23:06Zipanova@redhat.comipanova@redhat.com
<p>Add ability to skip sync of drpms when syncing yum rrepo</p> Container Support - Story #6635 (CLOSED - WORKSFORME): As a user I can export a set of repo versionshttps://pulp.plan.io/issues/66352020-05-04T12:47:49Zipanova@redhat.comipanova@redhat.com
<p>Add ContainerFileSystemExporter model, serializer, export and exporters viewsets</p> RPM Support - Story #5203 (CLOSED - WORKSFORME): As a user I can mirror content specified in extr...https://pulp.plan.io/issues/52032019-07-31T19:25:47ZdaviddavisPulp - Story #2757 (CLOSED - WORKSFORME): As an API user, a call to delete a Repository generates...https://pulp.plan.io/issues/27572017-05-15T19:17:01Zamacdona@redhat.comaustin@redhat.com
<p>After a discussion on the pulp-dev list [0], we decided that all updates and deletes for Publishers, Importers, and Repositories should be done asynchronously.</p>
<p>[0]: <a href="https://www.redhat.com/archives/pulp-dev/2017-May/msg00014.html" class="external">https://www.redhat.com/archives/pulp-dev/2017-May/msg00014.html</a></p> Pulp - Story #2656 (CLOSED - WORKSFORME): As a plugin developer, I can declare what platform plug...https://pulp.plan.io/issues/26562017-03-22T17:14:36Zsemyerssean.myers@redhat.com
<p>misa brought this up in a recent conversation, which was a desire for a plugin to be able to declare that it does not work unless the platform plugin API version is greater or less than a given version.</p>
<p>Functionally speaking, I think this means that a plugin <em>should</em> to be able declare a minimum-supported platform plugin API version and a maximum-supported plugin API version.</p>
<p>Comparator support could also be useful, so that for the minimum supported version a plugin developer could specify that the platform version must be "greater than" <em>or</em> "greater than or equal" to the platform plugin API version and for the maximum supported version a plugin develop could specify "less than" <em>or</em> "less than or equal to" a given platform plugin API version. Optionally, a simpler approach would be to declare that the minimum supported version evaluated by platform will always be evaluated as "greater than or equal" and the maximum supported version will always be evaluated as "less than".</p>
<p>So, for example, we introduce a new feature in 3.2 that results in a corresponding y-version bump of the plugin API version. Any plugin that requires that new feature to run should be able to report the minimum plugin API version required for that plugin to function.</p>
<p>Another example is if we alter a feature in 4.0, so that a plugin depending on that feature no longer works with 4.0. That plugin should be able to indicate that its maximum plugin API version is any version less than the corresponding platform plugin API version.</p>
<p>At the moment, I believe that the plugin API will be versioned separately from the platform code versioning. If we decide not to do that, then any mention of plugin API versioning should be changed to refer directly to the platform version.</p>
<p>This story is not concerned with what platform does, when loading plugins, if a plugin reports that it is incompatible with the Pulp platform that is loading it. We can file that story if this one is accepted, since there's minimal value in filing such a story if we don't first supply an interface for plugins to declare their compatibility.</p> Pulp - Task #2247 (CLOSED - WORKSFORME): Tracker for dependencies that need to be ported to Python 3https://pulp.plan.io/issues/22472016-09-12T14:48:43Zjcline@redhat.comjcline@redhat.com
<p>Our current dependencies can be seen at:</p>
<ul>
<li><a href="http://fedora.portingdb.xyz/pkg/pulp/" class="external">http://fedora.portingdb.xyz/pkg/pulp/</a></li>
<li><a href="http://fedora.portingdb.xyz/pkg/pulp-rpm/" class="external">http://fedora.portingdb.xyz/pkg/pulp-rpm/</a></li>
<li><a href="http://fedora.portingdb.xyz/pkg/pulp-puppet/" class="external">http://fedora.portingdb.xyz/pkg/pulp-puppet/</a></li>
<li><a href="http://fedora.portingdb.xyz/pkg/pulp-python/" class="external">http://fedora.portingdb.xyz/pkg/pulp-python/</a></li>
<li><a href="http://fedora.portingdb.xyz/pkg/pulp-ostree/" class="external">http://fedora.portingdb.xyz/pkg/pulp-ostree/</a></li>
<li><a href="http://fedora.portingdb.xyz/pkg/pulp-docker/" class="external">http://fedora.portingdb.xyz/pkg/pulp-docker/</a></li>
</ul>
<p>However, many of these dependencies may not be required in Pulp 3, or they may be replaced by better libraries. Assuming we pull in our old dependencies (sans m2crypto, okaara, and nectar), we'll need to port</p>
<ul>
<li>gofer</li>
<li>python-qpid</li>
<li>python-rhsm</li>
</ul> Pulp - Task #1900 (CLOSED - WORKSFORME): Test Redis as a celery broker transport in pulphttps://pulp.plan.io/issues/19002016-05-05T21:42:56Zmaxamillionmaxamillion@fedoraproject.org
<p>Currently Pulp officially supports qpid and rabbitmq as broker transports for celery, I would like to request that redis be offered as an option. If there is any more information needed, please let me know. Thank you.</p> Python Support - Task #1521 (CLOSED - WORKSFORME): TravisCI cannot install swighttps://pulp.plan.io/issues/15212016-01-13T15:54:37Zmhrivnakmhrivnak@redhat.com
<p>This job failed: <a href="https://travis-ci.org/pulp/pulp_python/jobs/99897974" class="external">https://travis-ci.org/pulp/pulp_python/jobs/99897974</a></p>
<p>Because "apt-get install swig" resulted in:</p>
<p>"E: Unable to locate package swig"</p>
<p>Perhaps the package was renamed? Or this was a temporary problem that's been fixed? Investigation is required.</p>
<p>The OS used by travis was Ubuntu 12.04.5 LTS, so it's unlikely that the package was renamed or removed.</p> Pulp - Task #520 (CLOSED - WORKSFORME): pulp.spec:547: W: libdir-macro-in-noarch-package agent %{...https://pulp.plan.io/issues/5202015-02-28T22:19:19Zrbarlow
<p>Description of problem:<br>
rpmlint -i pulp.spec gives the following warning:</p>
<p>pulp.spec:547: W: libdir-macro-in-noarch-package agent %{_libdir}/gofer/plugins/pulpplugin.*<br>
The %{_libdir}or %{_lib} macro was found in a noarch package in a section<br>
that gets included in binary packages. This is most likely an error because<br>
these macros are expanded on the build host and their values vary between<br>
architectures, probably resulting in a package that does not work properly on<br>
all architectures at runtime. Investigate whether the package is really<br>
architecture independent or if some other dir/macro should be instead.</p>
<p>gofer should use Python's entry point system to locate plugins rather than putting Python code in /usr/lib/.</p>
<p>Version-Release number of selected component (if applicable):<br>
2.4.0-1</p>
<p>How reproducible:<br>
Every time</p>
<p>Steps to Reproduce:<br>
1. Run rpmlint -i pulp.spec</p>
<p>Actual results:<br>
The above warning is printed.</p>
<p>Expected results:<br>
No warnings should be printed.</p>
<p>+ This bug was cloned from <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1141218" class="external">Bugzilla Bug #1141218</a> +</p> RPM Support - Task #144 (CLOSED - WORKSFORME): Ensure that DNF works with Pulp rpm reposhttps://pulp.plan.io/issues/1442015-02-05T14:53:01Zcduryeecduryee@redhat.com
<p>With Fedora 22 DNF will be the default instead of yum[0].</p>
<p>This task is to subscribe to a pulp rpm repo and download content with DNF. The output of this task is not necessarily to fix any issues but just to put in bugzilla entries for any breakage.</p>
<p>[0] <a href="http://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF" class="external">http://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF</a></p> Pulp - Story #21 (CLOSED - WORKSFORME): As a user, Pulp won't get into trouble if I accidentally ...https://pulp.plan.io/issues/212014-12-18T16:12:36ZAnonymous
<p>There are two things we can do to help this scenario:1) Have the babysit() function remember when it last babysat. If it hasn't been at least a minute since then, return. This will have the effect of letting us burn through the queue very quickly when there are a pile of tasks in it.2) Have the babysit() function accept the massaged output of the Celery active_queues() call as input. This Celery function takes on the order of seconds to complete, and could be done by any of the workers in the system. Whatever worker performs the work could also reduce the data structure down to just the workers and the queue names they are subscribed to so that the message can remain small. This will help the resource manager be more responsive in general as an added benefit.</p>