Adding postgresql-evr to Jenkins slaves

iballou · March 6, 2020, 7:41pm

I’m looking to get the postgresql-evr RPM installed on the Jenkins slaves so Katello tests can use it. What is the process for doing so? Alternatively, is installing postgresql-evr something that can happen during test time?

I don’t know too much about how the test pipeline works, but I’m curious what might have to happen when a new version of postgresql-evr is released. Will supporting multiple postgresql-evr versions for different versions of Katello be an issue?

ehelms · March 6, 2020, 8:59pm

The way we currently test, I anticipate this would be an issue. Do your forsee this happening with this plugin? Revving enough and varying enough to need to test it across different versions?

iballou · March 6, 2020, 9:09pm

I don’t envision postgresql-evr to be needing many revisions, but is it the case where one revision is already too much? I suppose it would be okay if we can maintain backwards compatibility. Looks like this is also going to be an issue for postgresql-debversion.

Justin_Sherrill · March 6, 2020, 9:12pm

Yeah, the only really way we plan to use it is going to be:

Creating a column of this custom type
calling a function within a few triggers to populate that column
Sorting by that column

The only update i could see is that if we found a bug within the functions or type definition itself, which seems like it could be resolved independent of the application. So i don’t see many updates to this, and if there are i imagine they would be fairly early into our implementation of it, and backwards compatible.

Justin_Sherrill · March 10, 2020, 1:13pm

BUMP, i believe we answered the raised questions, how do we go about
getting it added?

any update to this?

github.com

theforeman/foreman-infra/blob/master/puppet/modules/slave/manifests/init.pp

class slave (
  Optional[String] $github_user         = undef,
  Optional[String] $github_oauth        = undef,
  Optional[String] $jenkins_build_token = undef,
  Optional[String] $koji_certificate    = undef,
  Optional[String] $copr_login          = undef,
  Optional[String] $copr_username       = undef,
  Optional[String] $copr_token          = undef,
  Boolean $uploader                     = true,
  Stdlib::Absolutepath $homedir         = '/home/jenkins',
  Stdlib::Absolutepath $workspace       = '/var/lib/workspace',
) {
  # On Debian we use pbuilder with sudo
  $sudo = $facts['osfamily'] ? {
    'Debian' => 'ALL=NOPASSWD: ALL',
    default  => '',
  }

  users::account { 'jenkins':
    homedir => $homedir,

This file has been truncated. show original

Justin

ehelms · March 10, 2020, 3:59pm

You’d open a PR to add it here (https://github.com/theforeman/foreman-infra/blob/master/puppet/modules/slave/manifests/postgresql.pp). You’ll likely need to add configuration of the right repositories to init.pp.

ekohl · March 10, 2020, 4:14pm

I would like to avoid adding the regular Foreman repositories to all our slaves. Does it make sense to create a small infra yum repo for this?

ehelms · March 10, 2020, 4:35pm

We’d only be adding the Katello repository if that helps at all. I’d prefer to avoid a lot of overhead where possible.

ekohl · March 10, 2020, 4:38pm

IMHO the issue is still that you have to pick one release and ship that, potentially pulling in other things you don’t want.

On a related note: what are going to be the instructions for users who have deployed external PostgreSQL servers in their production envs? Install the Katello repo on your DB server(s)?

Justin_Sherrill · March 10, 2020, 4:47pm

Nightly could be that version.

yes, or just install the extension package manually.

I’m not opposed to an infra repo, but i dont have a strong opinion either way

ehelms · March 10, 2020, 8:15pm

We do this with CentOS and EPEL, SCLs. I am not seeing how our own repositories are suspect. I just wanted simple path. Now we need:

comps
hosting
jobs to generate the infra repo
rules around when we generate it

If we have other use cases for this I would be more in favor. @pcreech I am thinking to your investigations in pungi if this would be a secondary use case enough to bolster going that route.

pcreech · March 12, 2020, 7:55pm

So, from what I can gather, it seems there is enough cross-functional needs to provide non-standard packages (stuff not in base repos ) to support overall infrastructure efforts.

Many infrastructures do this. I know for a fact a lot of fedora/centos infra have custom built bits to support their environments.

With that, I think we’re at the point where we need to start working the direction of a standalone “infra” repo that we can build/tag packages into to distribute across our infrastrucutre.