Can't start Puppet server on latest version

[alanraison]

Describe the Bug

Upon a fresh clone (ref 094db0c9197efc570de6ff4f9e380a8769109064) of the repository, the puppet server fails to start with the error:

(LoadError) no such file to load -- concurrent

Expected Behavior

The Puppet server runs correctly

Steps to Reproduce

1. Clone the repository
2. Run docker-compose up

Environment

• Windows 10
• Docker 19.03.2
• Docker API: 1.40
• Repository version: 094db0c9197efc570de6ff4f9e380a8769109064

Additional Context

The compose file was modified to use an internal docker volume for the pgdata, rather than using a filesystem mount.

clojure-6866681218821049896.edn.txt

[scottcressi]

135 locks puppetserver version to a working image, waiting for that to be merged, images were never locked, they should be

[underscorgan]

Hi @alanraison ,

I started looking into this yesterday evening and will be digging in more today. I think for an easy work-around pinning the puppetserver version as @scottcressi suggested would be good, but will hopefully be able to get to the root cause of the issue.

[Xtigyro]

@underscorgan Both images that were released after 6.4.0 produce the error. So we're talking about 6.3.1 and 6.5.0.

[Niecke]

@Xtigyro But when using 6.4.0 I am running into #108 or does that work for you?

[scottcressi]

@underscorgan agreed pinning is the quick fix, I suggest we merge #135 and unblock the public, and in parallel we can fix whatever issue is blocking upgrading. It's no big deal that this image lags slightly until we fix it, #135 is about structure anyway, not images, the image versions themselves don't matter much in the grade scheme, especially bleeding edge. I'm sure we'll figure it out in the next few days/week/etc. anyway.

[underscorgan]

@scottcressi I'm going to pull the puppetserver pinning to a separate PR, I want to be able to think more about the puppetboard stuff. I'll get that pushed up this afternoon though, so hopefully things will be working again

[underscorgan]

I merged #137 in which pins to 6.4.0, which was working on my machine. Will work more on the puppetboard changes next week

[scottcressi]

@underscorgan Can we possibly do the exact same pinning for k8s? That needs to be fixed too, which was part of the previous pr, or shall I make a separate pr with all my previous PR changes minus puppetboard related changes

[underscorgan]

@scottcressi woops, sorry about that! Was pushing code right before I headed out for the day and missed k8s. Updated in https://github.com/puppetlabs/pupperware/pull/138

[Xtigyro]

@Xtigyro But when using 6.4.0 I am running into #108 or does that work for you?

@Niecke It works for me. I'm using the K8s stuff only.

[Niecke]

@Xtigyro Jep, you're right. When using puppet 6.4.0 and puppetdb latest everything is working finealso for docker-compose. I tried using 6.4.0 for puppet and puppetdb which was not working for docker-compose.

[Xtigyro]

@Xtigyro Jep, you're right. When using puppet 6.4.0 and puppetdb latest everything is working finealso for docker-compose. I tried using 6.4.0 for puppet and puppetdb which was not working for docker-compose.

@Niecke Yup - you can try exactly that with this PR: https://github.com/puppetlabs/pupperware/pull/135

[underscorgan]

The actual fix to the puppetserver container will be published out once https://github.com/puppetlabs/puppetserver/pull/2168 is merged in

[Xtigyro]

The actual fix to the puppetserver container will be published out once puppetlabs/puppetserver#2168 is merged in

@underscorgan Very nice - thank you!

[underscorgan]

the puppet/puppetserver:latest image should be working now, but I'm going to leave this open to make image tags parametrizable.