Replace artifactory.ovirt.org with Nexus

Description

Currently, Artifactory runs el7 and is managed by Puppet. This brings in extra work if we want to change something.

Let's build a new artifactory instance using Ansible and migrate workloads to it.

Activity

Show:
Evgheni Dereveanchin
March 21, 2020, 2:35 PM

looking at ovirt-engine sources, the only endpoint used on artifactory by builds is http://artifactory.ovirt.org/artifactory/ovirt-mirror

We need to create a simple Ansible playbook to install artifactory from RPM (jfrog.com/open-source) and set up the maven mirror at the above path.

Once that is done we can change the FQDN and move CI traffic to the new instance.

 

Other checks include verifying current settings and logs to see if any other endpoints are in use.

Here’s the current Puppet code that is managing the configuration of the existing instance:

Barak Korren
March 22, 2020, 3:04 AM

This may be a good time to switch from Artifactory (Proprietary) to Nexus (Open Source).

This may also be a good time to go from a VM to a container in OpenShift. The last time I checked, the Nexus project were providing a ready-to-go container image.

Evgheni Dereveanchin
March 22, 2020, 6:16 PM

Good point! We are actually providing nexus hosted on OpenShift already, however since it already has a DB it is not as easy to set up automatically as Artifactory. Let’s review the settings of both and get a maven cache working on the Nexus, then talk to the team to get the hardcoded cache overwritten or even better - make CI somehow provide the cache URL during the run instead of having to hard-code it in the sources.

Barak Korren
March 23, 2020, 4:26 AM

To make CI provide the Maven repo URL:

  1. Define a Jenkins global property with the URL (From the "Manage Jenkins"->"Configure System" screen under "Global properties")

  2. Add a [*.environment.yaml|https://ovirt-infra-docs.readthedocs.io/en/latest/CI/Build_and_test_standards/index.html#environment-dependencies] files to the engine`s automation configuration to expose the variable to the engine`s build scripts by using the valueFrom provider.

  3. Change the engine build code to use the provided value

Since we have a CI system, and most of the work would be done via sending patches to the engine repository, you would get automated verification for your work as you send the patches.

Note: You should ensure the build scripts do not crash if run in an environment that does not have the variable defined. This is done by:

  1. Making sure the build scripts can gracefully avoid using a cache server if the variable is not defined

  2. Marking the variable as optional in the *.environment.yaml files so that running mock-runner locally does not crash

Once you do this, it becomes possible to:

  1. Arbitrarily switch everyone to use a certain cache server in CI by changing a single configuration value in Jenkins

  2. Have different Jenkins servers use different cache server

  3. Test a new cache server by simply sending a temporary patch to the engine repo that modifies the *.environment.yaml files to point to a particular server by using a value field instead of a valueFrom field (Note that this approach is also possible now by changing the hard-coded values in the code).

Assignee

Shlomi Zidmi

Reporter

Evgheni Dereveanchin

Blocked By

None

Priority

Medium
Configure