Pulp: Issueshttps://pulp.plan.io/https://pulp.plan.io/favicon.ico2021-09-24T14:56:09ZPulp
Planio Pulp - Task #9447 (CLOSED - DUPLICATE): Write KCS for ACShttps://pulp.plan.io/issues/94472021-09-24T14:56:09Zppicka
<p><strong>Ticket moved to GitHub</strong>: "pulp/pulpcore/2055":<a href="https://github.com/pulp/pulpcore/issues/2055" class="external">https://github.com/pulp/pulpcore/issues/2055</a></p>
<hr>
<p>to follow <a href="https://issues.redhat.com/browse/SAT-1191" class="external">https://issues.redhat.com/browse/SAT-1191</a></p>
<p>should be written by pulp person</p> Pulp - Task #6746 (CLOSED - WONTFIX): Write up docs on how to develop/debug Travishttps://pulp.plan.io/issues/67462020-05-14T21:07:07Zdaviddavis
<p>Should include:</p>
<ul>
<li>How to create your own Travis fork</li>
<li>How to debug a problem in Travis</li>
</ul>
<p>Also, we should require that debugging be done on forks and not the pulp repository jobs.</p> RPM Support - Test #6313 (CLOSED - COMPLETE): Write tests to check sync optimizationhttps://pulp.plan.io/issues/63132020-03-10T01:50:20ZCodeHeeler
<p>Scenarios to test:</p>
<ol>
<li>First scenario
<ol>
<li>run sync (following our workflow docs) once,</li>
<li>there should be no optimization progress report on the task</li>
</ol>
</li>
<li>Second scenario
<ol>
<li>run sync a second time with no other changes,</li>
<li>there should be an optimization progress report now on the task</li>
</ol>
</li>
<li>Third scenario
<ol>
<li>run sync a third time adding the flag 'optimize=False',</li>
<li>there should be no optimization progress report now on the task</li>
</ol>
</li>
<li>Fourth scenario
<ol>
<li>create a new repo version,</li>
<li>run sync again (remove 'optimize=False' flag),</li>
<li>there should be no optimization progress report</li>
</ol>
</li>
<li>Fifth scenario
<ol>
<li>change remote policy to immediate,</li>
<li>run sync again,</li>
<li>there should be no optimization progress report</li>
</ol>
</li>
<li>Sixth scenario
<ol>
<li>ideally, we need a revision number change to the repomd in our fixtures (do we have a setup for this already? Is this within the scope of our automated tests)</li>
<li>run sync</li>
<li>there should be no optimization progress report now on the task</li>
</ol>
</li>
<li>Seventh scenario
<ol>
<li>run sync with no changes</li>
<li>there should be an optimization progress report now on the task</li>
</ol>
</li>
<li>Eighth scenario
<ol>
<li>run sync using the same repo, but a different remote</li>
<li>there should be no optimization progress report now on the task</li>
<li>rerun this sync</li>
<li>there should be an optimization progress report now on the task</li>
</ol>
</li>
</ol>
<p>All of these syncs should be run in succession without cleanup in between as a first time sync should always leave no optimization progress report. If for some reason you wanted to separate the tests and needed cleanup in between, every test scenario other than <a class="issue tracker-3 status-11 priority-6 priority-default closed child" title="Story: As a user, I can have Pulp attempt use auto_retry application wide using the 'unsafe_autoretry' p... (CLOSED - CURRENTRELEASE)" href="https://pulp.plan.io/issues/1">#1</a> will need to have sync run twice, once at the beginning, and once when specified after the stated changes for the test.</p> RPM Support - Task #6297 (CLOSED - CURRENTRELEASE): Write performance centos7 full sync test with...https://pulp.plan.io/issues/62972020-03-06T17:49:45Zbmbouterbmbouter@redhat.com
<p>We need to be able to measure a policy='immediate' sync of the CentOS7 repo:</p>
<p>We should mirror from Centos7: <a href="http://mirror.centos.org/centos/7/os/x86_64/" class="external">http://mirror.centos.org/centos/7/os/x86_64/</a></p> RPM Support - Task #5937 (CLOSED - WONTFIX): Write tests for checking applicability correctnesshttps://pulp.plan.io/issues/59372020-01-07T15:50:49ZCodeHeeler
<p>See the Testing portion of the Applicability Design doc:<br>
<a href="https://hackmd.io/ydvHuzXNRA6T9eXx6cqy5A#Testing" class="external">https://hackmd.io/ydvHuzXNRA6T9eXx6cqy5A#Testing</a></p>
<p>The correct-output for the fixture should be determined ‘by hand’ and written into a correctness-file associated with the test-suite. Tests against the known-quantity can then compare directly against the canonical-definition-of-correct data.</p> Pulp - Task #5721 (CLOSED - CURRENTRELEASE): Write the 'Promotion' workflow pagehttps://pulp.plan.io/issues/57212019-11-14T14:52:30Zbmbouterbmbouter@redhat.com
<p>This page is blank and it should be there: <a href="https://docs.pulpproject.org/en/3.0/nightly/workflows/promotion.html" class="external">https://docs.pulpproject.org/en/3.0/nightly/workflows/promotion.html</a></p> Ansible Plugin - Task #5368 (CLOSED - CURRENTRELEASE): Write galaxy-import result of contents and...https://pulp.plan.io/issues/53682019-08-28T21:11:22Zawcrosby
<p>The galaxy-importer result includes contents and docs_blob keys. The CollectionVersion model has attributes for these.</p>
<p>This data should be written when the galaxy-importer is called, in both the import_collection and sync workflows.</p> Pulp - Test #4179 (CLOSED - COMPLETE): Write Test applicability for modular or mixed contenthttps://pulp.plan.io/issues/41792018-11-21T23:21:20Zragbalak
<p>1) Test whether a rpm in module is applicable if appropriate<br>
Thus RPMs with versions lesser than the modules version should be applicable for new versions</p>
<p>2) Test Modules that are dependent on other modules.<br>
Modules that are dependent on another module, must be supported for applicability testing.</p>
<p>3) Test Whether both modular and non modular rpms can be tested for<br>
applicability<br>
Customer profile created with both modular/non modular rpms should be supported</p>
<p>4) Test applicability doesn't work for future RPM versions.<br>
Negative testcase if RPM version doesn't comply with the module's version.</p> Pulp - Test #3634 (CLOSED - COMPLETE): Write functional tests for task delete and cancel codehttps://pulp.plan.io/issues/36342018-04-30T20:59:51Zamacdona@redhat.comaustin@redhat.com
<p>Tests should successfully delete tasks in final states, and should not be able to delete tasks in waiting or running states.</p>
<p>Tests should successfully cancel tasks in waiting and running states, but should not be able to cancel tasks in final states.</p> Pulp - Task #3409 (CLOSED - WONTFIX): Write unit tests for task codehttps://pulp.plan.io/issues/34092018-02-27T23:47:14Zdaviddavis
<p>We have some task functionality that I don't think QE can test with pulp-smash:</p>
<p>Some examples:<br>
<a href="https://pulp.plan.io/issues/3226" class="external">https://pulp.plan.io/issues/3226</a><br>
<a href="https://pulp.plan.io/issues/3222" class="external">https://pulp.plan.io/issues/3222</a><br>
<a href="https://pulp.plan.io/issues/3186" class="external">https://pulp.plan.io/issues/3186</a></p>
<p>We need similar tests for Publications.</p>
<p>Also, it would be good to have a test to test out Task cancellation.</p> Pulp - Task #3058 (CLOSED - WONTFIX): Write docs about the tasking systemhttps://pulp.plan.io/issues/30582017-10-06T16:55:23Zbmbouterbmbouter@redhat.com
<p>The tasking system is a key part of how pulp works but it's not well documented in terms of the behaviors it provides. Having a basic flow diagram of tasks through the components would be good. Along with some identification of the API endpoints (through links to their docs) can be used to manage tasks.</p>
<p>I'm not sure where this should be, but we don't have much in terms of basic user information as a section. Maybe there should be a top-level section called 'Usage' and a subsection called 'Tasking System'. What do others think about this?</p> RPM Support - Story #2428 (CLOSED - NOTABUG): Write guide for using Ansible for managing RPM cont...https://pulp.plan.io/issues/24282016-11-17T20:42:44Zdkliban@redhat.com
<p>This guide should provide concrete examples of how to use Ansible for updating servers using repositories published by Pulp.</p>
<p>For each pulp-admin command for modifying content on a consumer the guide should provide equivalent workflow for Ansible.</p>
<p>The commands that need to be covered in this guide include:</p>
<p>Binding and unbinding Pulp repositories to/from consumer.<br>
<a href="http://docs.pulpproject.org/dev-guide/integration/rest-api/consumer/bind.html#bind-a-consumer-to-a-repository" class="external">http://docs.pulpproject.org/dev-guide/integration/rest-api/consumer/bind.html#bind-a-consumer-to-a-repository</a><br>
<a href="http://docs.pulpproject.org/dev-guide/integration/rest-api/consumer/bind.html#unbind-a-consumer" class="external">http://docs.pulpproject.org/dev-guide/integration/rest-api/consumer/bind.html#unbind-a-consumer</a></p>
<p>Installing, updating, and uninstalling packages on a consumer.<br>
<a href="http://docs.pulpproject.org/dev-guide/integration/rest-api/consumer/content.html" class="external">http://docs.pulpproject.org/dev-guide/integration/rest-api/consumer/content.html</a></p> RPM Support - Story #240 (CLOSED - NOTABUG): YUM repositories using deltainfo don't get delta RPM...https://pulp.plan.io/issues/2402015-02-19T01:18:33Zkvedulv@kvedulv.dekvedulv@kvedulv.de
<p>+<span>+ This bug was initially created as a clone of <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1120215" class="external">Bugzilla Bug #1120215</a> +</span>+</p>
<p>Description of problem:</p>
<p>Description of problem:<br>
YUM repositories using deltainfo instead of prestodelta don't get their Delta-RPMs synced into the published repo.</p>
<p>Version-Release number of selected component (if applicable):<br>
2.4beta23</p>
<p>How reproducible:<br>
always</p>
<p>Steps to Reproduce:<br>
1. Patch pulp with <a href="https://github.com/pulp/pulp_rpm/pull/525" class="external">https://github.com/pulp/pulp_rpm/pull/525</a> to work around missing name element im collection of SUSE repos.<br>
2. Import and publish attached test repo.<br>
3. Try a zypper update on the client.</p>
<p>Actual results:<br>
Delta RPMs are missing</p>
<p>Expected results:<br>
Delta RPMs are in the published repo</p>
<p>--- Additional comment from <a href="mailto:mhrivnak@redhat.com" class="email">mhrivnak@redhat.com</a> at 07/16/2014 16:30:58 ---</p>
<p>Thank you for finding both of these incompatibilities between pulp and SUSE content. We want to support SUSE content, and this will be very helpful in making that happen.</p>
<p>A diligent investigation of the schema for the deltainfo file vs. the prestodelta file will be required before we can implement this. Any additional help with that would be quite welcome.</p>
<p>--- Additional comment from <a href="mailto:kvedulv@kvedulv.de" class="email">kvedulv@kvedulv.de</a> at 07/16/2014 21:57:35 ---</p>
<p><a href="http://en.opensuse.org/openSUSE:Standards_Rpm_Metadata" class="external">http://en.opensuse.org/openSUSE:Standards_Rpm_Metadata</a> says:<br>
deltainfo.xml used to support delta rpms. Format is the same as yum-presto<br>
A glance at those deltainfo.xml files is also confirming that, so it shouldn't be hard to fix.</p>
<p>Unfortunately I don't have a clue how to handle that in the importer, as PRESTO_DELTA_FILE_NAME = 'prestodelta.xml.gz' doesn't leave much room for or-clauses. ;)</p>
<p>It would probably make sense to publish the contents of a generated prestodelta.xml also as deltainfo.xml so zypper/yast can consume it.</p>
<p>--- Additional comment from <a href="mailto:kvedulv@kvedulv.de" class="email">kvedulv@kvedulv.de</a> at 07/18/2014 11:03:45 ---</p>
<p>Workaround at <a href="https://github.com/pulp/pulp_rpm/pull/527" class="external">https://github.com/pulp/pulp_rpm/pull/527</a></p>
<p>--- Additional comment from <a href="mailto:bcourt@redhat.com" class="email">bcourt@redhat.com</a> at 01/12/2015 17:15:27 ---</p>
<p>Michael Moll, With some browsing & testing I did, it appeared that zypper will read the presto-delta.xml.gz file if it is in the repository. Can you confirm whether or not the file must be named deltainfo if zypper will use a presto-delta file if it is found instead.</p>
<p>There is another patch at <a href="https://github.com/pulp/pulp_rpm/pull/629" class="external">https://github.com/pulp/pulp_rpm/pull/629</a> that will ensure that all the information is synced into a pulp repository. It's just a matter of how it is published. In this case it is vastly simpler if we can always use presto-delta as the name of the output file.</p>
<p>--- Additional comment from <a href="mailto:kvedulv@kvedulv.de" class="email">kvedulv@kvedulv.de</a> at 01/16/2015 13:58:44 ---</p>
<p>After changing employers, I don't have a pulp instance around to test at the moment, sorry... If your tests are positive with zypper from SLES 11 SP3 (that's the oldest still supported, I think), I'd say just go ahead. If real testing is needed, ping me again and I'll setup something.<br>
Thanks for following up on that!</p> RPM Support - Story #38 (CLOSED - WONTFIX): Yum Plugins: Revisit search indexeshttps://pulp.plan.io/issues/382014-12-18T16:12:38ZAnonymousRPM Support - Story #27 (CLOSED - WONTFIX): Yum Plugins: Resolution for retain-old-count & errata...https://pulp.plan.io/issues/272014-12-18T16:12:37ZAnonymous
<p>Deliverable: decide what needs to happen, but don't write any new code decide if it is ok for --retain-old-count to break availability of RPMs for errata</p>