Pulp: Issueshttps://pulp.plan.io/https://pulp.plan.io/favicon.ico2021-04-28T07:07:15ZPulp
Planio Debian Support - Task #8643 (CLOSED - DUPLICATE): Rework the API docshttps://pulp.plan.io/issues/86432021-04-28T07:07:15Zquba42
<p><strong>Ticket moved to GitHub</strong>: "pulp/pulp_deb/405":<a href="https://github.com/pulp/pulp_deb/issues/405" class="external">https://github.com/pulp/pulp_deb/issues/405</a></p>
<hr>
<p>I would like to systematically go through the strings used for the API docs, to ensure they provide all the critical information for users.</p> Debian Support - Task #8641 (CLOSED - DUPLICATE): Review handling of ALLOWED_CONTENT_CHECKSUMS in...https://pulp.plan.io/issues/86412021-04-28T07:02:46Zquba42
<p><strong>Ticket moved to GitHub</strong>: "pulp/pulp_deb/403":<a href="https://github.com/pulp/pulp_deb/issues/403" class="external">https://github.com/pulp/pulp_deb/issues/403</a></p>
<hr>
<p>Right now we are testing using checksum settings that are not what most production setups will use.
The current settings also require manual intervention in devel boxes to run tests locally.</p>
<p>Ideally we would have different tests using different settings for full coverage.</p> Pulp - Task #8226 (CLOSED - CURRENTRELEASE): Remove # coding=utf-8 from plugin-templatehttps://pulp.plan.io/issues/82262021-02-08T18:18:29Zggainey
<p>Python3 defaults to utf8 now.</p> File Support - Task #8225 (CLOSED - DUPLICATE): Remove # coding=utf-8 from our testshttps://pulp.plan.io/issues/82252021-02-08T16:37:04Zggainey
<p><strong>Ticket moved to GitHub</strong>: "pulp/pulp_file/627":<a href="https://github.com/pulp/pulp_file/issues/627" class="external">https://github.com/pulp/pulp_file/issues/627</a></p>
<hr>
<p>Python3 defaults to utf8 now.</p> Pulp - Task #7908 (CLOSED - CURRENTRELEASE): Make sure all exceptions live in pulpcore.plugin.exc...https://pulp.plan.io/issues/79082020-12-01T13:38:59Zggainey
<p>See discussion at <a href="https://github.com/pulp/pulpcore/pull/1027#discussion_r524551412" class="external">https://github.com/pulp/pulpcore/pull/1027#discussion_r524551412</a></p>
<p>This will require a deprecation cycle, with a given exception living "in two places" for one release. Once this issue is in MODIFIED, open a new issue to complete the move.</p> Pulp - Task #7501 (CLOSED - DUPLICATE): Improve travis log output on migration-failureshttps://pulp.plan.io/issues/75012020-09-11T20:40:49Zggainey
<p><strong>Ticket moved to GitHub</strong>: "pulp/pulpcore/1934":<a href="https://github.com/pulp/pulpcore/issues/1934" class="external">https://github.com/pulp/pulpcore/issues/1934</a></p>
<hr>
<p>If a migration conflicts with one, the resulting failures in travis are...opaque. To whit:</p>
<pre><code> pulp: pulpcore.tasking.services.worker_watcher:INFO: Cleaning up shutdown worker '391@bf917f148de1'.
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/django/db/backends/utils.py", line 84, in _execute
return self.cursor.execute(sql, params)
psycopg2.ProgrammingError: relation "core_worker" does not exist
LINE 1: ...cefully_stopped", "core_worker"."cleaned_up" FROM "core_work...
</code></pre>
<p>Would be nice if it said "migration 00XX_foo conflicts with 00XX_bar" instead.</p> Pulp - Task #7476 (CLOSED - DUPLICATE): [Docs] Improve plugin API reference section of the guidehttps://pulp.plan.io/issues/74762020-09-09T02:51:15Zdalleydalley@redhat.com
<p><strong>Ticket moved to GitHub</strong>: "pulp/pulpcore/1933":<a href="https://github.com/pulp/pulpcore/issues/1933" class="external">https://github.com/pulp/pulpcore/issues/1933</a></p>
<hr>
<p><a href="https://docs.pulpproject.org/pulpcore/plugins/index.html#plugin-writer-s-guide" class="external">https://docs.pulpproject.org/pulpcore/plugins/index.html#plugin-writer-s-guide</a></p>
<p>Feedback from Gerrod:</p>
<blockquote>
<p>Knowing how Pulp works in order to make changes is definitely the most challenging aspect of contributing. I think the writer’s guide does a good job describing all the different aspects of Pulp and plugins. The plugin api reference section is a bit barren though.</p>
</blockquote>
<p>I think what he's referring to is that several sections like the models and viewsets have almost no description, but then other sections such as downloaders have a lot of detail.</p> Pulp - Task #7475 (CLOSED - CURRENTRELEASE): [Docs] Improve testing section of the pulp developer...https://pulp.plan.io/issues/74752020-09-09T02:47:21Zdalleydalley@redhat.com
<p><a href="https://docs.pulpproject.org/pulpcore/en/master/nightly/contributing/tests.html" class="external">https://docs.pulpproject.org/pulpcore/en/master/nightly/contributing/tests.html</a></p>
<p>Feedback from Gerrod:</p>
<blockquote>
<p>For testing it would be helpful to mention the fixtures and building local fixtures with pfixtures if a plugin uses them. It would be helpful to explicitly mention that you should use prestart before testing any changes. Also, running Pulp in the foreground is mentioned, but I think you should also mention pstop and individually stopping and starting the different parts of Pulp like the content server, since these parts are useful to test/debug on their own.</p>
</blockquote> Debian Support - Story #7315 (CLOSED - DUPLICATE): Adding RBAC (Role Based Access Control) suppor...https://pulp.plan.io/issues/73152020-08-12T11:29:26Zquba42
<p><strong>Ticket moved to GitHub</strong>: "pulp/pulp_deb/392":<a href="https://github.com/pulp/pulp_deb/issues/392" class="external">https://github.com/pulp/pulp_deb/issues/392</a></p>
<hr>
<p>pulpcore 3.6 adds experimental RBAC support. This may be declared safe to use with pulpcore 3.7.</p>
<p>Plugins can start taking advantage of this feature at their own choosing.</p>
<p>Plugin writers doc:</p>
<p><a href="https://github.com/pulp/pulpcore/tree/master/docs/plugins/plugin-writer/concepts/rbac" class="external">https://github.com/pulp/pulpcore/tree/master/docs/plugins/plugin-writer/concepts/rbac</a></p> Debian Support - Task #7024 (CLOSED - DUPLICATE): Add the ability to set per release/distribution...https://pulp.plan.io/issues/70242020-06-22T11:00:38Zquba42
<p><strong>Ticket moved to GitHub</strong>: "pulp/pulp_deb/387":<a href="https://github.com/pulp/pulp_deb/issues/387" class="external">https://github.com/pulp/pulp_deb/issues/387</a></p>
<hr>
<p>Right now, users can set the description at the repository level.
This description will be used in the Release file for all releases/distributions in the repository.</p>
<p>We could add a description field to the Release content model, that would override the repository description.</p>
<p>This would be a minor feature addition.</p> Container Support - Test #4461 (CLOSED - WONTFIX): As a user i can configure download of the fore...https://pulp.plan.io/issues/44612019-02-25T14:22:27Zbherring
<p>Some images like windows base images, contain artifacts whose distribution is restricted by license.<br>
When these images are pushed to a registry, restricted artifacts are skipped/not included by default.</p>
<p>These artifacts are called foreign layers and have "mediaType": "application/vnd.docker.image.rootfs.foreign.diff.tar.gzip"</p>
<p>Remote should have a Boolean "*allow_foreign_layers*" option which would control the download of the foreign layers.</p>
<p><strong>Set to False (default):</strong><br>
Pulp will check the mediatype and simply will skip the foreign layers.<br>
Case: do not sync content which is restricted by a license without explicit acknowledgment in the Remote config<br>
From client side, it will follow the url specified in the details of the layer in the manifest.</p>
<p><strong>Set to True:</strong><br>
Pulp will download the foreign layers by following the url.<br>
Case: due to use case of registries with air gaped network, now it's possible to push to the registry foreign layers, by enabling -allow-nondistributable-artifacts daemon option. From client side, foreign layers are now pulled from the registry if possible, falling back to the URLs in the image manifest otherwise. As far as i know that's done in docker for Windows. Linux version is still ignoring foreign layers during pull.</p> Container Support - Story #4400 (CLOSED - DUPLICATE): As a user, I can download Foreign layershttps://pulp.plan.io/issues/44002019-02-08T19:08:46Zamacdona@redhat.comaustin@redhat.com
<p><strong>Ticket moved to GitHub</strong>: "pulp/pulp_container/458":<a href="https://github.com/pulp/pulp_container/issues/458" class="external">https://github.com/pulp/pulp_container/issues/458</a></p>
<hr>
<p>A new field was added to skip foreign layers with this issue: <a href="https://pulp.plan.io/issues/4171" class="external">https://pulp.plan.io/issues/4171</a></p>
<p>The new field `include_foreign_layers` defaults to False and is not included on the Serializer, so for now it will always skip.</p>
<p>This story will require</p>
<ol>
<li>Add `include_foreign_layers` to the serializer</li>
<li>add logic to download the foreign layer, which will need to retrieve the layer with an absolute url instead of a relative url.</li>
</ol> Container Support - Story #4171 (CLOSED - CURRENTRELEASE): As a user i can configure download of ...https://pulp.plan.io/issues/41712018-11-19T10:23:15Zipanova@redhat.comipanova@redhat.com
<p>Some images like windows base images, contain artifacts whose distribution is restricted by license.<br>
When these images are pushed to a registry, restricted artifacts are skipped/not included by default.</p>
<p>These artifacts are called foreign layers and have "mediaType": "application/vnd.docker.image.rootfs.foreign.diff.tar.gzip"</p>
<p>Remote should have a Boolean "*allow_foreign_layers*" option which would control the download of the foreign layers.</p>
<p><strong>Set to False (default):</strong><br>
Pulp will check the mediatype and simply will skip the foreign layers.<br>
Case: do not sync content which is restricted by a license without explicit acknowledgment in the Remote config<br>
From client side, it will follow the url specified in the details of the layer in the manifest.</p>
<p><strong>Set to True:</strong><br>
Pulp will download the foreign layers by following the url.<br>
Case: due to use case of registries with air gaped network, now it's possible to push to the registry foreign layers, by enabling -allow-nondistributable-artifacts daemon option. From client side, foreign layers are now pulled from the registry if possible, falling back to the URLs in the image manifest otherwise. As far as i know that's done in docker for Windows. Linux version is still ignoring foreign layers during pull.</p> Debian Support - Task #4150 (CLOSED - WONTFIX): The pool folder structure could be improvedhttps://pulp.plan.io/issues/41502018-11-13T12:22:48Zquba42
<p>When publishing Debian repositories we currently use the following 'pool' folder structure:</p>
<pre><code class="text syntaxhl" data-language="text"><repo_base>/pool/<component>/<files>
</code></pre>
<p>For components like 'main' in Debian this leads to a huge number of files in a single folder.</p>
<p>For this reason the upstream Debian repositories use (one of) the following 'pool' folder structures:</p>
<pre><code class="text syntaxhl" data-language="text"><repo_base>/pool/<component>/<first_char_of_binary_package_name>/<binary_package_name>/<files>
<repo_base>/pool/<component>/lib<fourth_char_of_binary_package_name>/lib<rest_of_binary_package_name>/<files>
</code></pre>
<p>Once the refactoring from <a href="https://github.com/pulp/pulp_deb/pull/57" class="external">https://github.com/pulp/pulp_deb/pull/57</a> is merged, it would be relatively trivial to implement the same pool folder structure Debian uses in pulp_deb.</p> File Support - Task #3823 (CLOSED - WONTFIX): Analyze repository version creation performance for...https://pulp.plan.io/issues/38232018-07-06T16:40:45Zdkliban@redhat.com
<p>After the user has migrated content from Pulp 2 to Pulp 3, it will be necesary to migrate the repositories and the association between repos and content. There are 2 options for migrating the association:</p>
<p>- create a repository version by performing a sync from Pulp 2 repository<br>
- create a repository version by querying Pulp 2, find units in Pulp 3, create a repository version by specifying the pulp 3 units.</p>
<p>This task is to analyze the performance of the two methods of creating repository versions and provide guidance on how this part of the migration should be handled.</p>