Pulp: Issueshttps://pulp.plan.io/https://pulp.plan.io/favicon.ico2021-06-29T19:37:18ZPulp
Planio Pulp - Issue #8988 (CLOSED - CURRENTRELEASE): `pulpcore-worker` startup should remove old worker ...https://pulp.plan.io/issues/89882021-06-29T19:37:18Zbmbouterbmbouter@redhat.com
<a name="To-reproduce"></a>
<h2 >To reproduce<a href="#To-reproduce" class="wiki-anchor">¶</a></h2>
<ol>
<li>Start a pulpcore-worker against an empty database</li>
<li>Observe that the status API shows that worker</li>
<li>kill -9 your worker</li>
<li>Observe the status API after 30 seconds no longer shows your worker</li>
<li>Start your pulpcore-worker again</li>
<li>Go into shell_plus and observe this query shows 2 workers present: <code>Workers.objects.count()</code>
</li>
</ol>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<pre><code>In [1]: Worker.objects.count()
Out[1]: 1
</code></pre>
<a name="Solution"></a>
<h2 >Solution<a href="#Solution" class="wiki-anchor">¶</a></h2>
<p>Have workers that startup run a query that delete any workers that haven't issued a heartbeat in say 7 days. This does not need to be configurable. The 7 day idea is to make something that won't let records accumulate on the long term, but leave them in place for someone to look at the db post-mortem and still see them for investigation.</p> RPM Support - Issue #8229 (CLOSED - NOTABUG): Do not replace advisory if only 'updated_date' has ...https://pulp.plan.io/issues/82292021-02-09T07:18:23Zadam.winberg@smhi.se
<p>It seems that EPEL sets a new 'updated_date' every day, so when I run my daily sync I get:</p>
<pre><code> "content_summary": {
"added": {
"rpm.advisory": {
"count": 2540,
"href": "/pulp/api/v3/content/rpm/advisories/?repository_version_added=/pulp/api/v3/repositories/rpm/rpm/10e51ae6-65c7-42aa-8ab1-ffebdf752500/versions/19/"
},
"rpm.package": {
"count": 6,
"href": "/pulp/api/v3/content/rpm/packages/?repository_version_added=/pulp/api/v3/repositories/rpm/rpm/10e51ae6-65c7-42aa-8ab1-ffebdf752500/versions/19/"
}
},
"removed": {
"rpm.advisory": {
"count": 2536,
"href": "/pulp/api/v3/content/rpm/advisories/I've tested this and it works?repository_version_removed=/pulp/api/v3/repositories/rpm/rpm/10e51ae6-65c7-42aa-8ab1-ffebdf752500/versions/19/"
}
}
},
</code></pre>
<p>Inspecting the advisories, the only thing changed is the 'updated_date' metadata, version and package lists are identical. EPEL seems to set a new 'updated_date' each day on existing advisories, and in such a case there is not much sense in replacing the existing advisory with the 'new' one. I run weekly scripts to copy new advisories to a frozen repo which is a lot harder to do when thousands of new advisories are coming in every day.</p>
<p>I looked at the code ("pulp_rpm/app/advisory.py") and propose that an additional test is made in the "resolve_advisory_conflict" function, a crude example:</p>
<pre><code> elif not same_dates and pkgs_intersection:
if same_version and previous_pkglist == added_pkglist:
# Ignore new advisory if only 'updated_date' has changed
to_exclude.append(added_advisory.pk)
</code></pre> CertGuard - Issue #6424 (CLOSED - CURRENTRELEASE): An expired client RHSM Certificate should be d...https://pulp.plan.io/issues/64242020-03-31T19:43:21Zbmbouterbmbouter@redhat.comPulp - Issue #5985 (CLOSED - WORKSFORME): Status API reports incorrect versions installed for dev...https://pulp.plan.io/issues/59852020-01-14T19:21:29Zbmbouterbmbouter@redhat.com
<p>Using pulplift's box pulp3-source-fedora31 and pulpcore and pulp_file at these versions:</p>
<p>pulpcore==3.0.0<br>
pulp_file==0.1.0</p>
<p>Then I query the status API I sometimes see:</p>
<pre><code> "versions": [
{
"component": "pulpcore",
"version": "3.1.0.dev0"
},
{
"component": "pulp_file",
"version": "0.2.0.dev0"
}
]
</code></pre>
<p>An import from within the virtualenv confirms 3.0.0 is installed with:</p>
<pre><code>$ python
>>> from pulpcore import __version__
>>> __version__
'3.0.0'
</code></pre>
<p>I traced the issue to the way it's checked, there is something it doesn't like about checking it <a href="https://github.com/pulp/pulpcore/blob/c0fcdb7c58fb132c1913f917ac4dc0e7f2c21e59/pulpcore/app/views/status.py#L51" class="external">here</a></p> Pulp - Issue #3889 (CLOSED - CURRENTRELEASE): psycopg2 warninghttps://pulp.plan.io/issues/38892018-07-30T19:48:06Zbmbouterbmbouter@redhat.com
<p>Whenever the Pulp3 database driver connects to Postgresql it emits this warning:</p>
<pre><code>/home/vagrant/.virtualenvs/pulp/lib64/python3.6/site-packages/psycopg2/__init__.py:144: UserWarning: The psycopg2 wheel package will be renamed from release 2.8; in order to keep installing from binary please use "pip install psycopg2-binary" instead. For details see: <http://initd.org/psycopg/docs/install.html#binary-install-from-pypi>.
""")
</code></pre>
<p>It would be great to start Pulp3 without these warnings</p> Pulp - Issue #3095 (CLOSED - WONTFIX): Unable to cancel pending unstarted taskshttps://pulp.plan.io/issues/30952017-10-23T21:46:31ZAnonymous
<p>1. Created some consumers<br>
2. Created some consumer groups for patching<br>
3. Deleted some consumers<br>
4. Run some package group updates<br>
5. Task lists look Unstarted.</p>
<p>I am not able to cancel the tasks by running</p>
<p>pulp-admin tasks cancel --task-id <task-id></p>
<p>Is there a workaround to remove those orphan tasks?</p> Pulp - Issue #2100 (CLOSED - WONTFIX): Repositories with repo-id "search" cannot be updated or de...https://pulp.plan.io/issues/21002016-07-22T20:41:45Zamacdona@redhat.comaustin@redhat.com
<p>If the repo is named search, it's endpoint is /pulp/api/v2/repositories/search/ which conflicts with our search API.</p>
<p>If a user attempts to create this repo, there is no conflict.</p>
<p>If the user attempts to delete this repo, a 405 is returned because DELETE requests cannot go to the search API.</p>
<p>This has probably been around since as long as the search API and is therefore not a regression.</p> Pulp - Issue #1360 (CLOSED - WONTFIX): Permissions retrieval from API doesn't work as expectedhttps://pulp.plan.io/issues/13602015-11-05T21:01:10Zamacdona@redhat.comaustin@redhat.com
<p><a href="http://pulp.readthedocs.org/en/latest/dev-guide/integration/rest-api/permission/retrieval.html#retrieve-permissions-for-particular-resource" class="external">http://pulp.readthedocs.org/en/latest/dev-guide/integration/rest-api/permission/retrieval.html#retrieve-permissions-for-particular-resource</a></p>
<p><strong>tldr;</strong> Permissions API only returns resources that are explicitly granted, leaving out resources that are implicitly granted.</p>
<p>A user is authorized to use a resource if they have been explicitly granted access to that resource <strong>or</strong> if the user has been granted access to a base of the given resource.</p>
<p>So if the user "admin" has been given access to `/`, they will implicitly have permission to access `/repositories/`.</p>
<p>As an example, if we query the API to see what users have permission to use the resource `/`, since admin was explicitly granted permission to this url, we can see that admin has permission here.</p>
<pre><code>(pulp)[vagrant@dev pulp]$ http --json -a admin:admin --verify=no GET 'https://localhost/pulp/api/v2/permissions/?resource=/'
</code></pre>
<pre><code>HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Length: 191
Content-Type: application/json; charset=utf-8
Date: Thu, 05 Nov 2015 20:51:44 GMT
Keep-Alive: timeout=5, max=100
Server: Apache/2.4.16 (Fedora) OpenSSL/1.0.1k-fips mod_wsgi/4.4.8 Python/2.7.10
</code></pre>
<pre><code class="json syntaxhl" data-language="json"><span class="w">
</span><span class="p">[</span><span class="w">
</span><span class="p">{</span><span class="w">
</span><span class="nl">"_id"</span><span class="p">:</span><span class="w"> </span><span class="p">{</span><span class="w">
</span><span class="nl">"$oid"</span><span class="p">:</span><span class="w"> </span><span class="s2">"563a54c6e779892dc40d2a9b"</span><span class="w">
</span><span class="p">},</span><span class="w">
</span><span class="nl">"_ns"</span><span class="p">:</span><span class="w"> </span><span class="s2">"permissions"</span><span class="p">,</span><span class="w">
</span><span class="nl">"id"</span><span class="p">:</span><span class="w"> </span><span class="s2">"563a54c6e779892dc40d2a9b"</span><span class="p">,</span><span class="w">
</span><span class="nl">"resource"</span><span class="p">:</span><span class="w"> </span><span class="s2">"/"</span><span class="p">,</span><span class="w">
</span><span class="nl">"users"</span><span class="p">:</span><span class="w"> </span><span class="p">{</span><span class="w">
</span><span class="nl">"admin"</span><span class="p">:</span><span class="w"> </span><span class="p">[</span><span class="w">
</span><span class="s2">"CREATE"</span><span class="p">,</span><span class="w">
</span><span class="s2">"READ"</span><span class="p">,</span><span class="w">
</span><span class="s2">"UPDATE"</span><span class="p">,</span><span class="w">
</span><span class="s2">"DELETE"</span><span class="p">,</span><span class="w">
</span><span class="s2">"EXECUTE"</span><span class="w">
</span><span class="p">]</span><span class="w">
</span><span class="p">}</span><span class="w">
</span><span class="p">}</span><span class="w">
</span><span class="p">]</span><span class="w">
</span></code></pre>
<p>However,despite the fact that the admin user has access to `/repositories/` it has been granted access to `/`, access is not shown by the API.</p>
<pre><code>(pulp)[vagrant@dev pulp]$ http --json -a admin:admin --verify=no GET 'https://localhost/pulp/api/v2/permissions/?resource=/repositories/'
</code></pre>
<pre><code>HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Length: 2
Content-Type: application/json; charset=utf-8
Date: Thu, 05 Nov 2015 20:52:05 GMT
Keep-Alive: timeout=5, max=100
Server: Apache/2.4.16 (Fedora) OpenSSL/1.0.1k-fips mod_wsgi/4.4.8 Python/2.7.10
</code></pre>
<pre><code class="json syntaxhl" data-language="json"><span class="w">
</span><span class="p">[]</span><span class="w">
</span></code></pre> 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 #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> Pulp - Issue #979 (CLOSED - WONTFIX): Long consumer name cannot be usedhttps://pulp.plan.io/issues/9792015-05-12T18:21:14Zbmbouterbmbouter@redhat.com
<p>0) Have pulp installed and started<br>
1) As root, attempt to register a consumer and observe the following output:</p>
<pre><code>pulp-consumer -u admin -p admin register --consumer-id 482CRZDMRSQ63ASPM0LSN1YH8VX97UM5YA72R5Y7J482CRZDMRSQ63ASPM0LSN1YH8VX97UM5YA72R5Y7J482CRZDMRSQ63ASPM0LSN1YH8VX97UM5YA72R5Y7J482CRZDMRSQ63ASPM0LSN
An unexpected error has occurred. More information can be found in the client
log file ~/.pulp/consumer.log.
</code></pre>
<p>2) In ~/.pulp/consumer.log observe</p>
<pre><code>2015-05-12 14:17:05,920 - ERROR - Client-side exception occurred
Traceback (most recent call last):
File "/home/bmbouter/Documents/pulp/client_lib/pulp/client/extensions/core.py", line 478, in run
exit_code = Cli.run(self, args)
File "/usr/lib/python2.7/site-packages/okaara/cli.py", line 974, in run
exit_code = command_or_section.execute(self.prompt, remaining_args)
File "/home/bmbouter/Documents/pulp/client_lib/pulp/client/extensions/extensions.py", line 224, in execute
return self.method(*arg_list, **clean_kwargs)
File "/home/bmbouter/Documents/pulp/client_consumer/pulp/client/consumer/cli.py", line 148, in register
existing_consumer = load_consumer_id(self.context)
File "/home/bmbouter/Documents/pulp/client_lib/pulp/client/consumer_utils.py", line 47, in load_consumer_id
return subject['CN']
KeyError: 'CN'
</code></pre>
<p>The length limitations of consumer names are not documented, and they could be. Another thing would be to have the CN be the database record ID which would remove the relationship between a long consumer name and the CN altogether. I recommend doing that.</p> Pulp - Issue #613 (CLOSED - WONTFIX): Qpid ssl configuration not present on index on left of sphi...https://pulp.plan.io/issues/6132015-02-28T22:44:01Zbmbouterbmbouter@redhat.com
<p>There is a large page written on how to configure Qpid with SSL [0], but it is very hard to find. There is only one link in the installation guide that could take the user to this page. I expected it would be easier to find.</p>
<p>Suggestion: Add it to the index on the left side of the user guide so that users can find it.</p>
<p>[0]: <a href="https://pulp-user-guide.readthedocs.org/en/latest/qpid.html" class="external">https://pulp-user-guide.readthedocs.org/en/latest/qpid.html</a></p>
<p>+ This bug was cloned from <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1161729" class="external">Bugzilla Bug #1161729</a> +</p> Pulp - Issue #612 (CLOSED - WONTFIX): Add build step to build docs to create new version in redminehttps://pulp.plan.io/issues/6122015-02-28T22:43:56Zbmbouterbmbouter@redhat.com
<p>When building an actual it's important that a new version is requested from bugzilla admins so that when users use the release they can report bugs against it.</p>
<p>+ This bug was cloned from <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1161698" class="external">Bugzilla Bug #1161698</a> +</p> Pulp - Issue #599 (CLOSED - WONTFIX): Improve reporting docshttps://pulp.plan.io/issues/5992015-02-28T22:42:13Zbmbouterbmbouter@redhat.com
<p>This is a docs bug to add some things to the reporting area [0].</p>
<p>- A link to the bugzilla page<br>
- A feature versus a defect<br>
- A section on putting [RFE] at the front for a feature request<br>
- Some hints on including log messages on the server, not just the client<br>
- Removing the day that triage happens</p>
<p>[0]: <a href="http://pulp.readthedocs.org/en/latest/dev-guide/contributing/bugs.html#reporting" class="external">http://pulp.readthedocs.org/en/latest/dev-guide/contributing/bugs.html#reporting</a></p>
<p>+ This bug was cloned from <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1159065" class="external">Bugzilla Bug #1159065</a> +</p> Pulp - Issue #440 (CLOSED - WONTFIX): Restarting Pulp after changing concurrency left stale workershttps://pulp.plan.io/issues/4402015-02-28T22:09:10Zakrzos@redhat.comakrzos@redhat.com
<p>Description of problem:<br>
Change PULP_CONCURRENCY in /etc/default/pulp_workers prior to restarting pulp_resource_manager, pulp_workers, pulp_celerybeat has left several stale workers on my machine.</p>
<p>Version-Release number of selected component (if applicable):<br>
mod_wsgi-3.4-1.pulp.el6sat.x86_64<br>
pulp-puppet-tools-2.4.0-0.18.beta.el6sat.noarch<br>
m2crypto-0.21.1.pulp-10.el6sat.x86_64<br>
pulp-rpm-plugins-2.4.0-0.18.beta.el6sat.noarch<br>
pulp-katello-plugins-0.3-1.el6sat.noarch<br>
python-pulp-rpm-common-2.4.0-0.18.beta.el6sat.noarch<br>
python-pulp-bindings-2.4.0-0.18.beta.el6sat.noarch<br>
createrepo-0.9.9-21.2.pulp.el6sat.noarch<br>
python-pulp-common-2.4.0-0.18.beta.el6sat.noarch<br>
pulp-server-2.4.0-0.18.beta.el6sat.noarch<br>
pulp-nodes-parent-2.4.0-0.18.beta.el6sat.noarch<br>
pulp-nodes-common-2.4.0-0.18.beta.el6sat.noarch<br>
pulp-selinux-2.4.0-0.18.beta.el6sat.noarch<br>
python-isodate-0.5.0-1.pulp.el6sat.noarch<br>
python-pulp-puppet-common-2.4.0-0.18.beta.el6sat.noarch<br>
python-kombu-3.0.15-5.pulp.el6sat.noarch<br>
pulp-puppet-plugins-2.4.0-0.18.beta.el6sat.noarch</p>
<p>How reproducible:<br>
Always</p>
<p>Steps to Reproduce:<br>
1. change PULP_CONCURRENCY to < available cores on machine in /etc/default/pulp_workers while pulp is running<br>
2. service pulp_resource_manager restart; service pulp_workers restart; service pulp_celerybeat restart;<br>
3. view processes to see if stale processes remain</p>
<p>Actual results:<br>
Pulp only stops and restarts the number of workers as set to PULP_CONCURRENCY.</p>
<p>Expected results:<br>
Pulp should stop all Pulp workers and start only the number specified in PULP_CONCURRENCY or if the value is commented out then the default.</p>
<p>Additional info:</p>
<p>+ This bug was cloned from <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1102369" class="external">Bugzilla Bug #1102369</a> +</p>