Pulp: Issueshttps://pulp.plan.io/https://pulp.plan.io/favicon.ico2015-06-05T19:34:46ZPulp
Planio Docker Support - Refactor #1037 (CLOSED - CURRENTRELEASE): Remove manual setting for repo.repo_idhttps://pulp.plan.io/issues/10372015-06-05T19:34:46Zbcourtbcourt@redhat.com
<p>Remove manual setting of repo.repo_id = repo_transfer.id throughout Docker and OSTree plugins.</p>
<p>All other usages should already use repo_transfer.repo_obj to access the native object (with its id) from the repo_transfer object.</p> Nectar - Story #1031 (CLOSED - WONTFIX): Create a jenkins job to automatically test all Nectar PRshttps://pulp.plan.io/issues/10312015-06-04T13:56:12Zbcourtbcourt@redhat.com
<p>Create a jenkins job similar to the one for Pulp that automatically tests all PR requests</p> Crane - Story #1030 (CLOSED - WONTFIX): Create a jenkins job to automatically test all Crane PRshttps://pulp.plan.io/issues/10302015-06-04T13:54:55Zbcourtbcourt@redhat.com
<p>Create a Jenkins job similar to our plugin builders to automatically unit test all PRs automatically.</p> 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 - Story #934 (CLOSED - CURRENTRELEASE): Update mongoengine dependency to 0.9https://pulp.plan.io/issues/9342015-05-01T14:55:13Zbcourtbcourt@redhat.com
<p>After mongoengine 0.9 is released we should update the Pulp dependency from 0.7.10 to 0.9 across all our platforms.</p>
<p>Deliverables:</p>
<ul>
<li>Spec file updates for base dependency</li>
<li>pulp/server/pulp/server/db/manage.py:ensure_database_indexes() is updated to only use the Document.ensure_indexes() method</li>
<li>pulp/server/pulp/server/db/model/base.py:update_one() is removed</li>
</ul> Pulp - Refactor #888 (CLOSED - CURRENTRELEASE): pulp_manage_db needs to run .ensure_indexes() on ...https://pulp.plan.io/issues/8882015-04-14T18:57:37Zbcourtbcourt@redhat.com
<p>After pulp-manage-db performs all the migrations it should load all the models for the core collections (repos, tasks, repo_content_units, etc.) and run the ensure_indexes() method on the models to make sure that the Pulp required indexes are maintained.</p>
<p>Deliverables:</p>
<ul>
<li>Create a list that stores the class paths to provide the loading of all models for core collections</li>
<li>
<a href="https://pulp.plan.io/issues/765" class="external">Platform models that have already been converted</a> are included in the list of models above</li>
<li>Updates to pulp-manage-db calls ensure_indexes() on each loaded class in the list above</li>
<li>Mongoengine conversion guide is updated to include adding the model to this collection of calls.</li>
</ul> Pulp - Refactor #885 (CLOSED - WONTFIX): Remove all references to the AssociatedUnit, transfer un...https://pulp.plan.io/issues/8852015-04-10T17:58:44Zbcourtbcourt@redhat.com
<p>Remove all references to the AssociatedUnit, transfer units, & old content_types collection</p> Debian Support - Refactor #878 (CLOSED - CURRENTRELEASE): Convert pulp_deb to use MongoEngine modelshttps://pulp.plan.io/issues/8782015-04-10T17:35:20Zbcourtbcourt@redhat.com
<p>Convert the pulp_deb 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>
<li>Convert the model according to the <a href="https://fedorahosted.org/pulp/wiki/ConvertingModelsToMongoengine#StepsinvolvedinconvertingaPulpmodeltoMongoEngine" class="external">conversion guide</a>
</li>
</ul>
<p>Supported operations:</p>
<p>Milestone 1:</p>
<ul>
<li>Create repository to host deb packages</li>
<li>Add deb unit to deb repository (implementation detail: importer needs to work)</li>
<li>Publish apt repository (implementation detail: distributor needs to work)</li>
<li>Sign repository metadata within the distributor</li>
</ul>
<p>Milestone 2:</p>
<ul>
<li>Ability to sync a repo produced at milestone 1 (one dist, one component, one architecture)</li>
</ul>
<p>To be done later:</p>
<ul>
<li>Full mirror support - problematic for several reasons:
<ul>
<li>we need a way to keep track of which deb unit came from which dist/component/architecture</li>
<li>in order to not invalidate the repo metadata signature, we may have to save the repo metadata files and publish exactly those.</li>
</ul>
</li>
<li>Partial mirror
<ul>
<li>ability to specify a whitelist of dist/component/architecture combinations to be synced</li>
</ul>
</li>
</ul> OSTree Support - Refactor #876 (CLOSED - CURRENTRELEASE): Convert pulp_ostree to use MongoEngine ...https://pulp.plan.io/issues/8762015-04-10T17:32:26Zbcourtbcourt@redhat.com
<p>Convert the pulp_ostree 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> Docker Support - Refactor #863 (CLOSED - CURRENTRELEASE): Convert pulp_docker to use MongoEngine ...https://pulp.plan.io/issues/8632015-04-10T15:32:38Zbcourtbcourt@redhat.com
<p>Convert the pulp_docker 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> Crane - Story #260 (CLOSED - WONTFIX): [RFE] Crane should install a default /etc/crane.confhttps://pulp.plan.io/issues/2602015-02-19T01:19:48Zbcourtbcourt@redhat.com
<p>+<span>+ This bug was initially created as a clone of <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1150222" class="external">Bugzilla Bug #1150222</a> +</span>+</p>
<p>Description of problem:</p>
<p>Crane should create a default /etc/crane.conf that is commented out similarly to the /etc/pulp/server.conf.</p> Packaging - Task #151 (CLOSED - CURRENTRELEASE): Add automation to perform beta/release builds.https://pulp.plan.io/issues/1512015-02-06T19:17:26Zbcourtbcourt@redhat.com
<p>Assumptions:</p>
<ul>
<li>All projects built using this framework use the x.y-dev,x.y-testing,x.y-release</li>
<li>RPM signing is still completed manually</li>
<li>The spec files in the x.y-testing repository will have their versions bumped when the content is merged from x.y-dev or when the first new commit is added after a release build. This is not auto-bumped as part of the release build as we would have no way to know if no changes have been added to a project.</li>
</ul> Packaging - Task #89 (CLOSED - CURRENTRELEASE): Add automation to run unit tests for all PRs agai...https://pulp.plan.io/issues/892015-01-05T21:24:17Zbcourtbcourt@redhat.com
<p>Us the jenkins github pull request builder plugin to build all PRs against the core Pulp project automatically. This includes creating comments on the PRs indicating the success/failure of the test run.</p>
<p>This will require dynamically figuring out which nightly repo should be used to install the base pulp and plugin.</p>
<p>General procedure for running the unit tests</p>
<ol>
<li>Determine the base repository to install from</li>
<li>Install @pulp-server-qpid</li>
<li>Install the plugin that is being tested from RPM (this will ensure all dependencies are installed)</li>
<li>Uninstall the plugin that is being tested</li>
<li>Install the plugin from source</li>
<li>Run the tests</li>
</ol> Debian Support - Task #80 (CLOSED - CURRENTRELEASE): Design data model to support Debian reposhttps://pulp.plan.io/issues/802014-12-19T14:10:04Zbcourtbcourt@redhat.com
<p>Debian repositories support publishing multiple sub-repositories with a shared content folder. We need to figure out what that looks like in Pulp where a repositories have traditionally been much more monolithic.</p>