Infrastructure

So, i started to look at this. I was planning on doing that on openshift online, but my account is currently blocked (ticket is opened).

I am going to deploy that on www for the time being, but I do have some issues with that:

• the container is kinda big. I did fill the disk while doing tests, but I didn't looked if that's big and required, or big and need some cleanup from build artificats. I will take a look later once that's deployed, and make sure to cleanup podman on upgrade.

• that would be on 1 single server, which is not optimal for CI, in case we do reboot it.

Moving to openshift would alleviate the 2nd issue, cleaning the container would alleviate the 1st.

However, due to the use of HSTS, we would have to get a digicert certificate first, which requires likely a rather lengthy process. I will see with Duck about that.

Here is the PR: https://github.com/pulp/pulp-infra-ansible/pull/6

The service is almost ready, but I would like to requests that people keep a way to revert to previous CI in case anything happen. For example, I am still unsure that deployment of new system is working.

Quick summary. This is running directly in the container, we do not have any automated test to see if it work, and it will upgrade within 5 minutes to the latest pushed version. Among the problem that could arise, I see:

• filling the hard drive. A docker all time classic. I do not think we have monitoring on that server.
• having a dubious distro container not running well on a RHEL 7 system, due to "too old" or some weird selinux/apparmor issue.
• the host being blacklisted by

If people need to verify what is running, there is a service "systemctl status fixtures". The current version should be in ~/.current_fixtures as root, and all is done with a cronjob.

I still have a few things to fix before we can use it.

misc wrote:

Here is the PR: https://github.com/pulp/pulp-infra-ansible/pull/6

The service is almost ready, but I would like to requests that people keep a way to revert to previous CI in case anything happen. For example, I am still unsure that deployment of new system is working.

OK will do. We'll wait to take down the old ones until we get the OK from you.

Quick summary. This is running directly in the container, we do not have any automated test to see if it work, and it will upgrade within 5 minutes to the latest pushed version. Among the problem that could arise, I see:

• filling the hard drive. A docker all time classic. I do not think we have monitoring on that server.
• having a dubious distro container not running well on a RHEL 7 system, due to "too old" or some weird selinux/apparmor issue.
• the host being blacklisted by

If people need to verify what is running, there is a service "systemctl status fixtures". The current version should be in ~/.current_fixtures as root, and all is done with a cronjob.

OK we can document this in our fixtures usage docs. Can you link me to that actual file when it's online?

I still have a few things to fix before we can use it.

OK we'll standy. Thank you!

Also regarding the container's size: I suspect the container is legitimately big. It stores all the fixture data for all plugins (EL rpms, container content, ansible content, debian content, python content, file content, etc)