Pulp: Issueshttps://pulp.plan.io/https://pulp.plan.io/favicon.ico2021-07-02T18:07:29ZPulp
Planio Pulp - Task #9005 (NEW): pulp_installer's molecule CI should not always connect as roothttps://pulp.plan.io/issues/90052021-07-02T18:07:29Zmdepaulo@redhat.com
<p>This seems to be a product of, or the default configuration of, the docker plugin for molecule. (molecule uses <code>docker exec</code> to talk to the container, not SSH.)</p>
<p>We should look into performance options as we solve this. Even if it means eliminating/weakening SSH encryption on the CI environment / molecule containers.</p> Pulp - Task #8848 (NEW): pulp_installer to run CI against stable brancheshttps://pulp.plan.io/issues/88482021-06-01T21:20:04Zmdepaulo@redhat.com
<p>Currently, the source molecule tests test the master branch of pulpcore and master branch of plugins, rather than the appropriate branches like pulpcore 3.11 and pulp_rpm 3.11</p>
<p>So effectively we are relying on release jobs on old branches to catch errors, at release time.</p> Pulp - Task #8469 (NEW): Ensure the docker provider can be used for dev setupshttps://pulp.plan.io/issues/84692021-03-29T17:38:12ZdaviddavisPulp - Task #7811 (NEW): pulp_installer cron job runs functional tests for multiple plugins in FI...https://pulp.plan.io/issues/78112020-11-10T14:33:28Zdkliban@redhat.com
<p>The pulp_installer CI currently tests that it can deploy pulpcore and pulp_file in a FIPS environment. This cron job needs to install all plugins that support FIPS: pulp_file, pulp_rpm, pulp_container, and pulp_ansible.</p>
<p>After pulp is deployed, the functional tests for pulpcore, pulp_file, pulp_rpm, pulp_container, and pulp_ansible need to be run.</p> Pulp - Task #7724 (NEW): Improve runtime of new installation of Pulphttps://pulp.plan.io/issues/77242020-10-20T14:06:47Zbmbouterbmbouter@redhat.com
<p>The request to make the installer go faster</p>
<pre><code>A tower standalone install with automation hub takes about ~40 mins. Which is almost more than double of a normal
Tower install. It seems the most of the time we spent is on pulp-common role. Is there anything we are planning to do
in terms of making it little faster (not running same tasks many time, which pulp common role does) ?
</code></pre> Pulp - Task #7668 (NEW): remove pid files from the systemd service fileshttps://pulp.plan.io/issues/76682020-10-07T17:05:32Zdkliban@redhat.com
<p>Systemd does not need explicitly defined pid files to keep track of the services. We should make a change the systemd service files similar to the change here: <a href="https://github.com/theforeman/puppet-pulpcore/commit/b3b7c133c513dd2c30b00a81e64b2bb33ca92397" class="external">https://github.com/theforeman/puppet-pulpcore/commit/b3b7c133c513dd2c30b00a81e64b2bb33ca92397</a></p> Pulp - Task #7642 (NEW): Update pulp_installer's list of supported Fedora releaseshttps://pulp.plan.io/issues/76422020-10-01T18:18:58Zmdepaulo@redhat.com
<p>Fedora 32 is supported; pulplift CI tests it. Fedora 30 will probably be dropped in the task that blocks this.</p>
<p>Note that this list is in roles/*/meta/main.yml</p> Pulp - Task #7638 (NEW): Fix ansible_python_interpreter issues in pulp_installerhttps://pulp.plan.io/issues/76382020-10-01T18:03:57Zmdepaulo@redhat.com
<p>There are 3 minor / potential issues pertaining to this.</p> Pulp - Task #7575 (NEW): pulp_installer's SELinux support should handle folder paths being changedhttps://pulp.plan.io/issues/75752020-09-25T21:09:08Zmdepaulo@redhat.com
<p>pulp_install_dir, pulp_user_home, etc are currently baked into pulpcore-selinux.</p>
<p>pulp_installer should support accommodating this, such as by replacing the .fc file from pulpcore-selinux, or running label database commands.</p> Pulp - Task #7482 (NEW): pulp_installer change(s) for Recommended installation layouthttps://pulp.plan.io/issues/74822020-09-09T14:45:55Zmdepaulo@redhat.com
<p>See parent task.</p>
<p>We will just tell pulp_installer users to stop the services before upgrading, instead of the symlink. We will still perform the directory move though.</p> Pulp - Task #7313 (POST): The installer should be tested as a collectionhttps://pulp.plan.io/issues/73132020-08-12T09:53:56Zmdellweg
<p>We distribute the installer roles as a collection, and stuff in an ansible collection behaves different than outside, we need to test them as part of a collection.</p> Pulp - Task #7281 (NEW): Update docs to state that installer can only install one cluster at a timehttps://pulp.plan.io/issues/72812020-08-05T14:39:19Zdkliban@redhat.com
<p>The documentation needs to have a "Known limitations" section. One of the items should state that that the installer can only install one Pulp cluster at a time.</p> Pulp - Story #7043 (ASSIGNED): As a user, I have pulp_installer compile and install the pulpcore-...https://pulp.plan.io/issues/70432020-06-24T15:52:24Zdkliban@redhat.com
<a name="Overview"></a>
<h2 >Overview<a href="#Overview" class="wiki-anchor">¶</a></h2>
<p>On Red Hat systems, Pulp installer needs to clone pulpcore-selinux repository[0], compile the policy inside of it, and install the policy, label all the ports used by pulp services[1].</p>
<p>[0] <a href="https://github.com/pulp/pulpcore-selinux" class="external">https://github.com/pulp/pulpcore-selinux</a>
[1] <a href="https://github.com/pulp/pulpcore-selinux#labeling-pulpcore_port" class="external">https://github.com/pulp/pulpcore-selinux#labeling-pulpcore_port</a></p>
<a name="File-Path-RequirementsDetails"></a>
<h2 >File Path Requirements/Details<a href="#File-Path-RequirementsDetails" class="wiki-anchor">¶</a></h2>
<p>The SELinux policy is built assuming default file paths. For example things like /var/lib/pulp, etc. Those defaults are in the policy's ".fc" file <a href="https://github.com/pulp/pulpcore-selinux/blob/master/pulpcore.fc" class="external">here</a>.</p>
<p>On producton systems when these paths are changed the compiled policy will need to generate a correct .fc file to use when compiling the policy.</p>
<p>On dev systems, a new .fc file will need to be generated as well for the dev environment.</p>
<p>Alternatively, we can call commands/modules to update the label database with these changed paths.</p>
<a name="install-from-RPM-mode"></a>
<h2 >install-from-RPM mode<a href="#install-from-RPM-mode" class="wiki-anchor">¶</a></h2>
<p>Currently not needed (Dennis & Mike), the policies get installed (pre-compiled) via pulpcore-selinux RPM package, which the installer defaults to installing.</p>
<p>Because /usr/bin/rq and /usr/bin/gunicorn are generic, this mode will require wrapper scripts like Katello creates. If we are to support this mode at all (usually policies are in a separate RPM package.)</p>
<a name="Which-version-of-pulpcore-selinux-gets-installed"></a>
<h2 >Which version of pulpcore-selinux gets installed?<a href="#Which-version-of-pulpcore-selinux-gets-installed" class="wiki-anchor">¶</a></h2>
<p>Currently the "master" branch. Alternatives, like tagged releases, are TBD.</p>
<a name="How-to-test-branches-of-pulpcore-selinux"></a>
<h2 >How to test branches of pulpcore-selinux?<a href="#How-to-test-branches-of-pulpcore-selinux" class="wiki-anchor">¶</a></h2>
<p>The git repo and branch ("master") are configurable via 2 private variables, but there is no "Required PR" support because it is a lot of work and may not pay off. They can be overriden via <code>__pulp_selinux_repo</code> and <code>__pulp_selinux_version.</code> We should set these in molecule vars files for CI when needed.</p>
<a name="Provide-support-for-disabling-SELinux-in-the-installer"></a>
<h2 >Provide support for disabling SELinux in the installer?<a href="#Provide-support-for-disabling-SELinux-in-the-installer" class="wiki-anchor">¶</a></h2>
<p>This is worth considering in case an incompatible plugin will be installed. However, universally disabling SELinux is outside of of the scope of the installer now.</p>
<a name="Installing-the-1-package-for-the-ports-should-be-in-pulp_api-amp-pulp_content-roles"></a>
<h2 >Installing the 1 package for the ports should be in pulp_api & pulp_content roles.<a href="#Installing-the-1-package-for-the-ports-should-be-in-pulp_api-amp-pulp_content-roles" class="wiki-anchor">¶</a></h2>
<p>Doing so would be ideal, but our current implementation of installing it in pulp_common is good enough. (Dennis & Mike)</p>
<a name="Also-install-the-policy-for-the-other-selinux-modes-mls-strict-amp-targeted-not-just-the-current-one"></a>
<h2 >Also install the policy for the other selinux modes (mls, strict & targeted), not just the current one.<a href="#Also-install-the-policy-for-the-other-selinux-modes-mls-strict-amp-targeted-not-just-the-current-one" class="wiki-anchor">¶</a></h2>
<p>Current is good enough, we do only targeted for Pulp 2. (Dennis & Mike)</p>
<a name="Support-for-dev-mode-installs-with-pulp-source-installed-in-editable-mode"></a>
<h2 >Support for dev mode installs, with pulp source installed in editable mode?<a href="#Support-for-dev-mode-installs-with-pulp-source-installed-in-editable-mode" class="wiki-anchor">¶</a></h2>
<p>Tracked via: <a href="https://pulp.plan.io/issues/97" class="external">https://pulp.plan.io/issues/97</a></p> Pulp - Story #6797 (ASSIGNED): [epic] As a user, I can consume all the plugin prereq roles in the...https://pulp.plan.io/issues/67972020-05-21T18:45:22Zmdepaulo@redhat.com
<p>pulp_rpm_prerequisites exists because the installer has had a plugin neutral policy.</p>
<p>This policy was for very long misunderstood: It's not about avoiding favoritism to any plugins, it's about not tying the installer (which is tied to pulpcore releases) to plugin releases. So that say pulpcore 3.3 logic would be in pulp_installer 3.3 release, and so that pulp_cardboardbox 0.7 logic would be in the pulp_cardboardbox_prerequisites 0.7 role.</p>
<p>The team now agrees that this policy is counter-productive because:</p>
<ol>
<li>Having a role in a separate repo (not part of the pulp_installer collection) is extra work for developers, and for users.</li>
<li>The only plugin that currently needs a prereq role, pulp_rpm, has version numbers and releases that correspond to pulpcore releases. pulp_rpm 3.3.z needs pulpcore 3.3.z, etc. So the pulp_rpm specific installation logic can be safely bundled in pulp_installer 99% of the time.</li>
</ol> Pulp - Task #6306 (ASSIGNED): Request EPEL8 versions of packages in the pulp-devel rolehttps://pulp.plan.io/issues/63062020-03-06T21:22:23Zmdepaulo@redhat.com
<p>This PR has to do some workarounds for EL8 support, because the packages were not in EPEL8 yet:
<a href="https://github.com/pulp/ansible-pulp/pull/243/files#" class="external">https://github.com/pulp/ansible-pulp/pull/243/files#</a></p>
<p>Ignoring some helpful developing tools packages:
jnettop
fd-find
fzf</p>
<p>and Installing F28 (Python 3.6) versions of a package we needt:
python3-virtualenvwrapper</p>
<p>and its deps:
python3-virtualenv-clone
python3-stevedore</p>
<p>We should request that they be packaged for EPEL8.
See "## Consumer request for packages"
<a href="https://lists.fedoraproject.org/archives/list/epel-announce@lists.fedoraproject.org/thread/KXMMLYSAXAVHDKFFBVEFYYZHPJBWXOQQ/" class="external">https://lists.fedoraproject.org/archives/list/epel-announce@lists.fedoraproject.org/thread/KXMMLYSAXAVHDKFFBVEFYYZHPJBWXOQQ/</a></p>
<p>And then added to the list of packages to install as normal.</p>