Pulp: Issueshttps://pulp.plan.io/https://pulp.plan.io/favicon.ico2021-06-01T21:12:19ZPulp
Planio Pulp - Story #8846 (NEW): As a pulp_installer user, I do not need to use the latest micro release...https://pulp.plan.io/issues/88462021-06-01T21:12:19Zmdepaulo@redhat.com
<p>Basically, this means that pulp_installer 3.14.0 (or possibly 3.13.1 / 3.13.2) will be able to install pulpcore 3.14.z .</p>
<p>The benefit for users is that they will not need to always have the latest micro version of pulp_installer.</p>
<p>And the benefit to the pulp team is that we will not need to do a pulp_installer micro release for every pulpcore micro release.</p>
<p>This is a variation of the 1 year old proposal for versions/branches in pulp_installer, and a variation of the specific micro release policy we implemented originally in <a class="issue tracker-3 status-1 priority-6 priority-default child parent" title="Story: As a user, I can download & run a version of the ansible installer that a specific version of Pulp 3 (NEW)" href="https://pulp.plan.io/issues/5618">#5618</a>.</p>
<p>Reference from <a class="issue tracker-3 status-1 priority-6 priority-default child parent" title="Story: As a user, I can download & run a version of the ansible installer that a specific version of Pulp 3 (NEW)" href="https://pulp.plan.io/issues/5618">#5618</a>:</p>
<pre><code> * Original discussion:
* [mikedep333's proposal](https://github.com/pulp/pulp_installer/pull/203#issue-361269733)
* [bmbouter's couter-proposal to do micro-versioned releases](https://github.com/pulp/pulp_installer/pull/203#issuecomment-577903411)
* [mikedep333's agreement/details for micro-versioned releases](https://github.com/pulp/pulp_installer/pull/203#issuecomment-579450153)
</code></pre> Pulp - Backport #8835 (NEW): Backport pulp_installer FIPS fix to 3.11https://pulp.plan.io/issues/88352021-05-27T18:42:39Zironfroggy
<p>Current open ticket for FIPS issue: <a href="https://pulp.plan.io/issues/8834" class="external">https://pulp.plan.io/issues/8834</a></p> Pulp - Story #8702 (NEW): As a user, the example-use playbook is not cluttered with object storag...https://pulp.plan.io/issues/87022021-05-05T13:31:24Zmdepaulo@redhat.com
<p>We should move the object storage checks from the the example-use playbook to the pulp_common role to solve this.</p>
<p>It will provide a better user experience. (Making the example playbook as small as possible.)</p>
<p>It will also enforce the checks for users that do not use the example-use playbook.</p>
<p><a href="https://github.com/pulp/pulp_installer/blob/master/playbooks/example-use/playbook.yml" class="external">https://github.com/pulp/pulp_installer/blob/master/playbooks/example-use/playbook.yml</a></p>
<p><a href="https://github.com/pulp/pulp_installer/blob/master/roles/pulp_common/tasks/main.yml#L16" class="external">https://github.com/pulp/pulp_installer/blob/master/roles/pulp_common/tasks/main.yml#L16</a></p> Pulp - Story #8701 (NEW): As a pulp_installer user, I can use the full logic to add repos to the ...https://pulp.plan.io/issues/87012021-05-05T12:59:40Zmdepaulo@redhat.com
<p>As mentioned in <a class="issue tracker-1 status-11 priority-6 priority-default closed" title="Issue: pulp_installer fails to install redis due to no EPEL7 (CLOSED - CURRENTRELEASE)" href="https://pulp.plan.io/issues/7773">#7773</a> , we should refactor our logic to add repos to the system (in a robust & configurable manner) into another role like <code>pulp_repos</code>.</p>
<p>I propose the following design:</p>
<ol>
<li>This is a dependency role. pulp_common, pulp_redis, pulp_database, will all depend on it.</li>
<li>When a role like pulp_common depends on it, it passes variables like <code>__pulp_repos_epel: true</code> to denote which repos the role needs. It passes variables via roles/pulp_common/meta/main.yml : <code>dependencies:</code>
</li>
<li>If a user wants to disable the logic to add the repo (if they added it manually), they'll pass a variable like <code>pulp_repos_epel: false</code> to disable it.</li>
<li>Existing variables for configuring how we add the repos to the system, like <code>epel_release_packages</code>, should still used.</li>
</ol>
<p>This logic is found in:</p>
<ul>
<li>roles/pulp_common/tasks/ambiguously-named-repo.yml</li>
<li>roles/pulp_common/tasks/repos.yml</li>
</ul> Pulp - Story #8491 (NEW): As a user I only download needed collections dependencieshttps://pulp.plan.io/issues/84912021-03-31T20:31:18Zfao89
<p>As some modules are leaving ansible core to collections, we need to declare collections as dependencies so ansible-galaxy can install them.</p>
<p>pulp_installer provides a set of roles, and the user may not use all the roles, pulp_database role needs community.postgresql for example.</p>
<p>How can we deal with these "conditional dependencies"?
"if the user gets pulp_dabase role install community.postgresql else don't install it"</p>
<p><a href="https://github.com/pulp/pulp_installer/pull/567" class="external">https://github.com/pulp/pulp_installer/pull/567</a></p> Pulp - Story #8086 (NEW): pulp_installer should use latest version of pip to install packageshttps://pulp.plan.io/issues/80862021-01-13T13:42:45Zdkliban@redhat.com
<p>The newer versions of pip include an improved dependency resolution mechanism. The pulp_installer needs a task added to upgrade pip before installing any pulp packages.</p> Pulp - Story #7689 (NEW): As a user I want my socket to be backed up by a systemd implementationhttps://pulp.plan.io/issues/76892020-10-12T13:25:04Zspredzy
<p>As a user I want my socket to be backed up by a systemd implementation.</p>
<p>Under its current form, the installer allows one to use unix domain socket, but not to configure them with a native systemd implementation. This is a RFE for this.</p> Pulp - Story #7247 (NEW): As a pulp_installer developer-user, the pulp_rpm signing service will b...https://pulp.plan.io/issues/72472020-07-30T19:56:47Zmdepaulo@redhat.com
<p>The current way pulp_rpm's signing service needs to be installed is a temporary.</p>
<p>So let's add the current ansible-based solution I already developed. I developed it as part of the selinux el8 dev env, and it's in the pulp_devel (not meant for end users.)</p> Pulp - Story #7100 (NEW): As an admin I want to be able to ratelimit access to the api endpointshttps://pulp.plan.io/issues/71002020-07-07T14:09:57Zmdellweg
<p>In the most simple way, this can be added solely by adjusting the settings.
We should test this and document it with the installer.</p>
<p><a href="https://www.django-rest-framework.org/api-guide/throttling/" class="external">https://www.django-rest-framework.org/api-guide/throttling/</a></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 #7007 (NEW): As a user, I do not have to worry about Pulp being accidentally upgrade...https://pulp.plan.io/issues/70072020-06-18T15:40:06Zmdepaulo@redhat.com
<p>We should pursue using dnf versionlock to accomplish this.</p>
<p>This is needed because handlers/tasks "Run database migrations" will not be run if users run <code>dnf update</code>. Pulp would be broken until users re-run the installer.</p> Pulp - Story #6914 (NEW): nginx listen port and ip can not be configured with a variablehttps://pulp.plan.io/issues/69142020-06-05T12:18:38ZPixelfool
<p>In an IPV6 environment, it is necessary to configure the port and IP address for binding. <br>
In roles/pulp_webserver/templates/nginx.conf.j2, line 34, the configuration default is:</p>
<pre><code class="text syntaxhl" data-language="text">server {
listen 80 default deferred;
...
}
</code></pre>
<p>One solution could be</p>
<pre><code class="text syntaxhl" data-language="text">server {
listen {{ pulp_nginx_bind }} default deferred;
...
}
</code></pre>
<p>Expected result:</p>
<pre><code class="text syntaxhl" data-language="text">server {
listen [2001:db8::1]:80 default deferred;
...
}
</code></pre> Pulp - Story #6688 (NEW): pulp_installer: preflight check and system-wide packages are incompatiblehttps://pulp.plan.io/issues/66882020-05-08T14:40:15Zmdepaulo@redhat.com
<p>Part of the pre-flight check does not understand system-wide packages, but another part is still affected by them.</p>
<p>This leads to false positives (enforcements) in addition to false negatives in the preflight check.</p>
<p>We no longer need system-wide packages, so we should remove support for it, and migrate user installs off of it, as safely as possible.</p> 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> Pulp - Story #5618 (NEW): As a user, I can download & run a version of the ansible installer that...https://pulp.plan.io/issues/56182019-10-25T08:37:28Zmdepaulo@redhat.com
<p>Currently users are encouraged to get the latest ansible-pulp roles via git cloning. Later on, Ansible Galaxy.</p>
<p>The only stable tag ever done was 3.0.0rc1. Presumably we will create them for 3.0.0 and later.<br>
<a href="https://github.com/pulp/ansible-pulp/releases" class="external">https://github.com/pulp/ansible-pulp/releases</a></p>
<p>However, consider the following scenario (hypothetical release dates):<br>
1. They download the roles (either method) on Apr 1. They are versioned as 3.0.3 and install pulp 3.0.3<br>
2. They run them against their test env and it works.<br>
3. Pulp 3.1.0 & ansible-pulp 3.1.0 are released on Apr 15.<br>
4. They run the 3.0.3 roles against their prod env on May 1.<br>
5. The 3.0.3 roles try to install pulp 3.1.0 from pip, but fails due to the lack of new logic.</p>
<p>It would make sense to have a variable for the pulp version to install, that defaults to the same version as the roles, but can be overriden (but doing so is discouraged.)</p>
<p>Plugin versions would also be an issue. Let's discuss how this can be handled.</p>
<p>Also, I am not sure if there is an existing task for publishing the roles (other than pulp_rpm_prerequisites) to Ansible Galaxy (pulp project on it.):<br>
<a href="https://galaxy.ansible.com/pulp" class="external">https://galaxy.ansible.com/pulp</a></p>