Pulp: Issueshttps://pulp.plan.io/https://pulp.plan.io/favicon.ico2015-06-04T13:56:12ZPulp
Planio 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 - 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 - Story #880 (CLOSED - WONTFIX): Remove the types.json method of specifying modelshttps://pulp.plan.io/issues/8802015-04-10T17:48:50Zbcourtbcourt@redhat.com
<ul>
<li>Remove support in pulp-manage-db for reading types.json</li>
<li>remove the content_types database collection and all remaining references to it</li>
<li>Update server initialization to only use the models from the entry point</li>
<li>remove support for /usr/lib/pulp/plugins/types & and all references to it</li>
</ul> Pulp - Story #854 (CLOSED - NOTABUG): Create a plugin to support syncing & publishing Maven artif...https://pulp.plan.io/issues/8542015-04-09T14:27:32Zbcourtbcourt@redhat.com
<p>This content has been moved here: <a href="https://pulp.plan.io/projects/pulp/wiki/Maven_Plugin" class="external">https://pulp.plan.io/projects/pulp/wiki/Maven_Plugin</a></p>
<hr>
<p>Create an initial framework for supporting syncing & publishing <a href="https://maven.apache.org/what-is-maven.html" class="external">Maven</a> artifacts from within Pulp. This issue is an ok place for planning and gathering comments and information, but that should be broken up into smaller stories if/when implemented.</p>
<a name="Deliverables"></a>
<h2 >Deliverables<a href="#Deliverables" class="wiki-anchor">¶</a></h2>
<ul>
<li>A plugin module for maven artifacts
<ul>
<li>The plugin supports creating maven repositories</li>
<li>As a user, I can provide a URL, and possibly some additional information about how to discover specific content, that Pulp will use to sync a remote repository.</li>
<li>The plugin supports deleting maven repositories</li>
<li>As a user syncing from a remote Pulp, I only need to provide a URL to sync. Additional information about how to discover content should not be necessary.</li>
<li>The plugin supports uploading of maven modules to a repository</li>
<li>The plugin DOES NOT support lazy loading or syncing content from maven central</li>
</ul>
</li>
<li>CLI support for creating maven repositories</li>
<li>CLI support for deleting maven repositories</li>
<li>CLI support for uploading a maven artifact</li>
<li>CLI support for deleting a maven artifact</li>
</ul>
<a name="Questions"></a>
<h2 >Questions<a href="#Questions" class="wiki-anchor">¶</a></h2>
<a name="archetype-catalogxml"></a>
<h3 >archetype-catalog.xml<a href="#archetype-catalogxml" class="wiki-anchor">¶</a></h3>
<p>Some maven repositories appear to have an index of content named <a href="https://repository.jboss.org/nexus/content/repositories/releases/archetype-catalog.xml" class="external">archetype-catalog.xml</a>, and some <a href="http://jcenter.bintray.com/" class="external">do not</a>. What are the expectations around that file? When is/should it be present?</p>
<p>When Pulp does a sync, if that catalog is not present, we will need some other way for a user to specify what content to get. Should they provide a pom.xml file to the importer? Or perhaps csv/json that enumerates the content to get?</p>
<p>When Pulp does a publish, is it always safe for it to create an archetype-catalog.xml file? It is handy to have so that other Pulp deployments can sync from it and duplicate the exact same content.</p>
<a name="SNAPSHOT"></a>
<h3 >SNAPSHOT<a href="#SNAPSHOT" class="wiki-anchor">¶</a></h3>
<p>Should Pulp support "snapshot" repositories?</p>
<p><a href="https://blog.packagecloud.io/eng/2017/03/09/how-does-a-maven-repository-work/#snapshot-repositories" class="external">https://blog.packagecloud.io/eng/2017/03/09/how-does-a-maven-repository-work/#snapshot-repositories</a></p>
<p>The challenge is that the content with a given unique identifier that includes "-SNAPSHOT" can change from one sync to the next, and there's no way to know if it did. So it would need to be downloaded every time. We would also have to accept that if the content had been promoted into an additional repository, it could get updated in-place without another promote operation.</p>
<a name="Upload"></a>
<h3 >Upload<a href="#Upload" class="wiki-anchor">¶</a></h3>
<p>Is there a use case for upload? What does that look like? In what format would data get uploaded?</p>
<a name="References"></a>
<h2 >References<a href="#References" class="wiki-anchor">¶</a></h2>
<ul>
<li><a href="https://blog.packagecloud.io/eng/2017/03/09/how-does-a-maven-repository-work/" class="external">https://blog.packagecloud.io/eng/2017/03/09/how-does-a-maven-repository-work/</a></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> Pulp - Story #259 (CLOSED - WONTFIX): [RFE] Automatically load global configuration for pluginshttps://pulp.plan.io/issues/2592015-02-19T01:19:44Zbcourtbcourt@redhat.com
<p>+<span>+ This bug was initially created as a clone of <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1150162" class="external">Bugzilla Bug #1150162</a> +</span>+</p>
<p>Description of problem:</p>
<p>Description of problem:</p>
<p>Currently all plugins have to specify their global configuration file and load it manually. The platform should automatically look for a server/plugin.conf.d/<plugin_id>.ini file and use that for the global plugin configuration.</p> Pulp - Story #258 (CLOSED - WONTFIX): [RFE] Use the same configuration file format everywhere in ...https://pulp.plan.io/issues/2582015-02-19T01:19:41Zbcourtbcourt@redhat.com
<p>+<span>+ This bug was initially created as a clone of <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1150153" class="external">Bugzilla Bug #1150153</a> +</span>+</p>
<p>Description of problem:</p>
<p>Currently we have configuration files in both INI and JSON format. The server plugin.conf.d format is json and the rest of the pulp configuration files are in ini format. This is confusing to the user. We should use the same format for<br>
configuration files everywhere. I would propose that we use ini files everywhere since as a format it allows us to include comments that show all the valid keys that could be filled in.</p>
<p>--- Additional comment from <a href="mailto:mhrivnak@redhat.com" class="email">mhrivnak@redhat.com</a> at 10/10/2014 16:20:50 ---</p>
<p>This will definitely impact katello, so keep them in the loop.</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> Pulp - Task #85 (CLOSED - CURRENTRELEASE): Add automation to run unit tests for all PRs against p...https://pulp.plan.io/issues/852015-01-02T18:06:20Zbcourtbcourt@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> Puppet Support - Story #83 (CLOSED - CURRENTRELEASE): As a user I can install puppet modules usin...https://pulp.plan.io/issues/832014-12-19T21:40:05Zbcourtbcourt@redhat.com
<p>As a user I can install a module using the puppet module install command line using the v3 forge api enumerated at <a href="https://forgeapi.puppetlabs.com/" class="external">https://forgeapi.puppetlabs.com/</a></p>
<p>This will entail creating a new /v3/releases endpoint. We will have to go back to the pre-puppet 3.3 method of determining the repository and consumer as the ability to specify a context root has been disabled.</p>
<p>The api now requires pagination, offset tracking, and providing the urls for the next/previous queries in the case of pagination.<br>
There are now many more options for filtering.</p>
<p>We will only have to support the /v3/releases endpoint at this time.</p> 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> Pulp - Task #79 (CLOSED - WONTFIX): Move Nodepool to a dedicated locationhttps://pulp.plan.io/issues/792014-12-18T23:39:22Zbcourtbcourt@redhat.com
<p>Currently nodepool is running on a personal workstation. It should be moved to either a dedicated server, a docker image or an openshift gear that has more of an uptime guarantee</p>