Pulp: Issueshttps://pulp.plan.io/https://pulp.plan.io/favicon.ico2021-06-01T21:20:04ZPulp
Planio 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 - 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 - 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 #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 #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 - 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 #6942 (NEW): Update galaxy_ng docs for the pulp_installer install-from-rpm supporthttps://pulp.plan.io/issues/69422020-06-09T15:45:37Zmdepaulo@redhat.com
<p>Its docs should show the example variables for doing this.</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 - 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 - Story #5832 (NEW): As a developer, ansible-pulp will provide me with the cool postgres WebGUIhttps://pulp.plan.io/issues/58322019-12-03T22:35:56Zmdepaulo@redhat.com
<p>The following PoC was done. For implementation, it can be incorporated into the pulp-devel role, and pulplift.</p>
<p>On the host, reconnect to the pulplift VM pulp3-source-fedora31 with a new SSH tunnel (this will be added to pulplift config during implementation):</p>
<pre><code>vagrant ssh pulp3-source-fedora31 -- -L 8443:127.0.0.1:8443
</code></pre>
<p>On the pulplift VM pulp3-source-fedora31:</p>
<p>Modified /var/lib/pgsql/data/pg_hba.conf to replace the 127.0.0.1 line with:</p>
<pre><code>host all all 0.0.0.0/0 md5
</code></pre>
<p>(Because the container has a NAT'd IP address.)</p>
<p>Modified /var/lib/pgsql/data/postgresql.conf to contain</p>
<pre><code>listen_addresses = '*'
</code></pre>
<p>(Because otherwise it's localhost only; see above.)</p>
<pre><code>sudo systemctl restart postgresql.service
sudo dnf install -y podman-docker
docker pull dpage/pgadmin4
# "--restart always" will be ignored for podman-docker. Only real docker/moby-engine will use it. podman will need a systemd unit to survive VM reboots.
docker run --restart always -p 8443:8443 -e 'PGADMIN_DEFAULT_EMAIL=user@domain.com' -e 'PGADMIN_DEFAULT_PASSWORD=SuperSecret' -e 'PGADMIN_LISTEN_PORT=8443' -d dpage/pgadmin4
</code></pre>
<p>Now back on your host:</p>
<p>Open your browser to:<br>
<a href="http://127.0.0.1:8443/" class="external">http://127.0.0.1:8443/</a><br>
And login with the username/email and password listed above.</p>
<p>Then create a new connection to:<br>
The IP address of the pulplift VM<br>
database: pulp<br>
user: pulp<br>
password: pulp<br>
(These settings will later be set via PGADMIN_SERVER_JSON_FILE)</p>
<p>Rererence:<br>
<a href="https://www.pgadmin.org/docs/pgadmin4/latest/container_deployment.html#examples" class="external">https://www.pgadmin.org/docs/pgadmin4/latest/container_deployment.html#examples</a></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>