Pulp: Issueshttps://pulp.plan.io/https://pulp.plan.io/favicon.ico2020-10-20T14:06:47ZPulp
Planio 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 - 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 - 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 #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 #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 #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 #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 #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 - Task #6904 (NEW): Document using https://pypi.org/project/pulpcore-releases/ for the insta...https://pulp.plan.io/issues/69042020-06-03T15:25:07Zbmbouterbmbouter@redhat.com
<p>The Pulp Dependency Checker is a great tool to show compatibility between a pulpcore version and various concerns.</p>
<p>We should do three things:</p>
<ol>
<li>
<p>Move the pdc tool to the pulp org.</p>
</li>
<li>
<p>Add a very obvious link to the pulp_installer docs recommending users to use the tool to determine pulpcore and plugin compatibility</p>
</li>
<li>
<p>Update the error message that the installer puts out when the pre-flight check fails. Have that error message point users to specifically check which plugins are compatible with the pulpcore version the installer is trying to install.</p>
</li>
</ol> Pulp - Task #6798 (NEW): Document the new guidelines for plugin installation logichttps://pulp.plan.io/issues/67982020-05-21T18:47:54Zmdepaulo@redhat.com
<p>There are 3 places they could be:</p>
<ol>
<li>A role in a separate git repo and on galaxy.</li>
<li>A separate role in the pulp_installer repo (pulp_rpm will be this.)</li>
<li>Conditional logic within the pulp_installer's other roles.</li>
</ol> 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 #6747 (NEW): Demo video for pulp_installerhttps://pulp.plan.io/issues/67472020-05-14T21:48:07Zfao89
<ul>
<li>Video should not have audio</li>
<li>
<a href="https://asciinema.org/" class="external">https://asciinema.org/</a> - records terminal output and can be embedded in our docs and in the README on github</li>
<li>include RPM and Container plugins</li>
</ul> 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>