https://github.com/jboss-container-images/openjdk/blob/d908decf65a30bc179f29d25286daf5ff630696e/README.adoc#centos-jdk-11 documentation says that I should be able to build Community image CentOS JDK 11 as follows:

cekit --overrides-file=centos7-jdk11-overrides.yaml build

This currently does not work, and fails with:

...
ERROR    The md5 computed for the 'target/image/hawkular-javaagent-1.0.1.Final-redhat-2-shaded.jar' file ('1f55173d84e4ac52d0ee542e251d8b02') doesn't match the 'f97f623e5b614a7b6d1eb5ff7158027b' value
...
ERROR    Error copying resource: 'hawkular-javaagent'. See logs for more info.

I gather it would need a similar hack like #58, but it seems one can only specify one --overrides-file so how do you want to handle this?

I learnt in #48 that, quote:

To workaround the issue, you can create a ~/.cekit/config file which contains:

[repositories]
jboss-os=dummy-url
jboss-rhscl=dummy-url

this does seem to do the trick, but:

1. it's weird that such a work around is needed at all?

2. this is not currently documented on the README ...

3. this seems to lead to the following confusing message: WARNING The way of defining repository 'jboss-os' is deprecated. Convert it to an URL based repository object. Consult Cekit docs, for more details.

Weprobably don't need the PATH environment variable definition in the runtime image descriptors, which was used to add /usr/local/s2i for the builder images.

By default, the java s2i image is not included natively within the community list of okd.

This is really disadvantageous as we can't install SpringBoot, Vert.x or even Thorntail projects on okd excepted if we install manually this java s2i imagestream (or if we configure minishift to use the addon xpaas able to install the official redhat java s2i image)

Is it possible for you to submit a PR to the openshift/library project in order to have it part of okd ?

It would be useful if the script would by default understand Quarkus apps.

I think the "uber-jar" build layout already works (but it would have to be tested to be sure), but the other two layouts are not. The "legacy-jar" one always creates two jars (one xxx.jar and one xxx-runner.jar, it's the latter that's needed) plus a lib folder, while the new "fast-jar" option creates an entire folder with a bunch of files (including the dependencies in a lib folder and even a third jar with the fixed name quarkus-app.jar).

@jmtd point re. "image variant... should it include Maven" in #56 remind me of another RFE:

This S2I builder image should let users build with a newer/older Maven version than the one included by default. The easiest way that I know of to enable this, that I know of, is to let the S2I script detect the presence of the Maven Wrapper (which fixes a version).

We can take (strong) inspiration from "prior art" worked on over here to implement this:

• https://github.com/fabric8io-images/s2i/pull/152/files

On Fedora 28:

dnf copr enable @cekit/cekit
sudo dnf copr enable @cekit/cekit
git clone [email protected]:jboss-container-images/openjdk.git
cd openjdk
cekit build
2018-12-07 01:45:14,980 cekit        INFO     Generating files for docker engine.
2018-12-07 01:45:14,993 cekit        INFO     Initializing image descriptor...
2018-12-07 01:45:16,894 cekit        WARNING  The way of defining repository 'jboss-os' is deprecated. Convert it to an URL based repository object. Consult Cekit docs, for more details.
Traceback (most recent call last):
  File "/usr/bin/cekit", line 11, in <module>
    load_entry_point('cekit==2.2.2', 'console_scripts', 'cekit')()
  File "/usr/lib/python3.6/site-packages/cekit/cli.py", line 289, in run
    Cekit().parse().run()
  File "/usr/lib/python3.6/site-packages/cekit/cli.py", line 223, in run
    discover_modules(os.path.join(self.args.target, 'repo'))
  File "/usr/lib/python3.6/site-packages/cekit/module.py", line 92, in discover_modules
    'module.yaml'))))
  File "/usr/lib/python3.6/site-packages/cekit/descriptor/module.py", line 31, in __init__
    self._prepare()
  File "/usr/lib/python3.6/site-packages/cekit/descriptor/image.py", line 89, in _prepare
    self._descriptor['packages'] = Packages(self._descriptor['packages'])
  File "/usr/lib/python3.6/site-packages/cekit/descriptor/packages.py", line 59, in __init__
    self._prepare()
  File "/usr/lib/python3.6/site-packages/cekit/descriptor/packages.py", line 63, in _prepare
    for x in self._descriptor.get('repositories', [])]
  File "/usr/lib/python3.6/site-packages/cekit/descriptor/packages.py", line 63, in <listcomp>
    for x in self._descriptor.get('repositories', [])]
  File "/usr/lib/python3.6/site-packages/cekit/descriptor/packages.py", line 77, in __init__
    descriptor = self._create_repo_object(descriptor)
  File "/usr/lib/python3.6/site-packages/cekit/descriptor/packages.py", line 112, in _create_repo_object
    descriptor['url']['repository'] = self._get_repo_url(descriptor)
  File "/usr/lib/python3.6/site-packages/cekit/descriptor/packages.py", line 121, in _get_repo_url
    configured_repository_names = configured_repositories.keys()
AttributeError: 'NoneType' object has no attribute 'keys'

the module jboss.container.util.pkg-update causes a package manager update to run. But we have not hooked it into any images.

See https://github.com/jboss-container-images/openjdk/runs/2164676988?check_suite_focus=true

It broke with commit e26463c but I believe that to be a coincidence. I tihnk the troublesome line is

 virtualenv -p python3.6 ~/cekit${{ env.CEKIT_VERSION }}

error output is

RuntimeError: failed to find interpreter for Builtin discover of python_spec='python3.6'

The workflows reference ubuntu-latest which points at Ubuntu 20.04. The transition to 20.04 began in November 30, 2020.

I'm testing a revert to 18.04 here, but fixing the workflow for 20.04 is probably worthwhile. It might be as simple a changing the -p python3.6 line to 3.7 or newer.

Source 2 image builds using the openjdk image do not seem to empty /tmp before flattening and shipping the image. This results in the application source code, which is copied to /tmp/src, to be included in the image.
If you specify a reference in openshift for the git source, this does a full clone of the repository, which can lead to images that are larger than they should be.

Is there a way to have /tmp emptied? Or is the right approach to override the assemble script and do it yourself?

I'm building on OpenShift 3.7 with redhat-openjdk-18/openjdk18-openshift:1.5.

cekit can now copy a content_sets file into dist-git, so we should add it to the image sources instead of manually committing it to dist-git behind the scenes. This will mean if/when we introduce new (dist-git) branches the content_sets.yml file will be automatically put in the right places.

Related to #57 but i decided against co-opting that particular issue

Some notes

cekit needs odcs-client which needs libkrb5-dev (gssapi.h) even if odcs stuff is not defined in the YAMLs.

The image FROM names are not obviously resolveable, e.g.
ubi8-minimal:8-released needs to be mapped to registry.access.redhat.com/ubi8/ubi-minimal:latest. The simplest solution is to locally tag the image e.g.

podman tag registry.access.redhat.com/ubi8/ubi-minimal:latest ubi8-minimal:8-released

later

Error: Problems in request:
missing groups or modules: maven:3.6

Could the maven packages not have made it into the UBI set? Or local network issues here

This S2I Builder image IMHO really should ("out of the box") support Gradle in addition to Maven.

We can take (strong) inspiration from the following "prior art" work done to implement this here:

• https://developers.redhat.com/blog/2018/12/18/openshift-java-s2i-builder-java-11-grade/
• fabric8io-images/s2i#118
• fabric8io-images/s2i#121
• fabric8io-images/s2i#151
• https://github.com/fabric8io-images/s2i/pull/158/files
• fabric8io-images/s2i#150 (still TBD)
• fabric8io-images/s2i#161 (example end-user interest)

@jmtd I find it curious that this repo/project is named "openjdk" (under jboss-container-images) when, in fact, it's not (just) an OpenJDK container image, but an S2I builder image (based on OpenJDK). Is it too late to rename this to something like s2i-openjdk or openjdk-s2i ? And perhaps (now or in the future) have a separate repo/project named "openjdk" for an image with the community version of a CentOS/Fedora OpenJDK container, automatically kept up-to-date, but without the S2I stuff. Just a thought.

Should we add a label that points containers built from this repository back to it? Maybe populate vcs-url as per https://github.com/projectatomic/ContainerApplicationGenericLabels

For Red Hat Product images, vcs-ref is populated by our build system, but I don't think the ref maps back to this repository, but to the intermediate build repository where assets are collated for reproducible building.

We have some tests in this repo, I think because at some point the tooling (cekit) could not collate tests from external modules, but now it can. We should move some tests to be adjacent to the code they are testing, e.g. https://github.com/jboss-container-images/openjdk/blob/develop/tests/features/java/gc.feature to go next to https://github.com/jboss-openshift/cct_module/tree/master/jboss/container/java/jvm/api

We have already introduced develop as the default branch to replace openjdk18-dev. The former is a decendent of the latter (via a merge), so we could reconstruct openjdk18-dev from the history of develop if we wished to. We should delete openjdk18-dev as it should no longer be used.

We still have openjdk18 as the release branch. We should introduce a new release branch (perhaps simply release) as a successor in a similar way, and delete the openjdk18 branch.

I'm interested in being able to locally build this project myself (for #51) but still failing miserably.

Originally #48, but currently not even get that far anymore.

I'll open more specific issues, and link them here; I'l close this issue when I can actually locally build this project easily.

Hey @jmtd

We've had some user/customer confusion recently between those two imagestreams, and in particular some difficulty with openjdk-8-rhel8:1.2 (the latest tag) because it was still using v1 schema

conversely, the redhat-openjdk18-openshift:1.8 tag appears to be v2 schema

there are also questions coming in because of the "rhel8" name and whether they run on rhel7 (openshift still has to support rhel7 worker nodes) ... if that is the case, that would be an issue for openshift and installing that sample imagestream.

is openjdk-8-rhel8 more legacy and no longer being worked on? if so, can it be removed? if not, can we get an update with v2 schema?

when you get a sec let us know what is up ... thanks !!

@bparees FYI

I tried using openj9/openj9-11-rhel8 instead of the registry.access.redhat.com/ubi8/openjdk-11 for s2i binary build and go the error below:

error: build error: error building at STEP "RUN chown -R 185:0 /tmp/src": error while running runtime: exit status 1

I get this behavior in a quarkus project that uses the quarkus-openshift extension for generating the BuildConfig and initiating the build. As mentioned above everything works fine with images like the registry.access.redhat.com/ubi8/openjdk-11 but fails with using openj9/openj9-11-rhel8

The runtime images need override files in the redhat/ directory, similar to the regular images.

For example cp redhat/ubi8-openjdk-8.yaml redhat/ubi8-openjdk-8-runtime.yaml, and make some changes:

• delete java-<version>-openjdk and java-<version>-openjdk-devel
• alter the branch: key to add -runtime after JDK major version eg openjdk-11-ubi8 => openjdk-11-runtime-ubi8

I think that should be it!

Discussion in #58 got me thinking whether it makes sense for the oldest (now deprecated) RHEL7-based image should be image.yaml, the default target when someone invokes cekit build [builder]. Especially since those images cannot be trivially built (#57)

Perhaps we should track the latest/supported/preferred image with image.yaml instead (UBI8/JDK11).

We could do it in phases, phase one might be to rename image.yaml but not put a new image.yaml in place (and fix any problems in CI/CD etc)

A later phase might be to add a symlink from image.yaml to the preferred image.

Couldn't openj9-11-* be added as alternatives to openjdk-11-* here, since at least the latter (unlike openjdk-8) does have a JIT for Z? That would not contradict making openj9 the defaults for the java imagestream.

Originally posted by @yselkowitz in #116

fabric8io-images/s2i#218

hey @jmtd

In case you check github jira issues more closely than bugzillas :-) I'm opening this to alert you to a problem with the openjdk8 imagestream for openshift

All the gory details are in https://bugzilla.redhat.com/show_bug.cgi?id=1946663

fyi I had to open a BZ instead of a jira so I can mark an openshift bz I have "officially" dependent / blocked by the changes we need on your end

thanks

We could register cct_module as a git submodule under path ./modules and simplify the YAML to

path: modules

The main advantage would be not requiring every single cekit invocation to clone a fresh copy of cct_module from GitHub. We would move the specific git ref tracking out of the YAML and into the .gitmodules file. That's one place instead of one-per image YAML. Potential disadvantage: we could not vary the cct_module version/ref in use on a per-image basis. But we certainly could on a per-branch basis.

Another drawback is the need, after a fresh clone of this repo, to git submodule init etc. This requirement would be on any CI/CD tooling built on top of cekit too.

There are GH workflows for the full JDK images. We should have CI (thus, pr tests) for the new runtime images as well.

@jmtd OK. I brought it up because the github actions checks fail:

Failing scenarios:
  features/cct_module/jboss/container/s2i/core/bash/s2i-core.feature:7  run an s2i build and check that /tmp/src has been removed afterwards
  features/image/java/gc.feature:7  Check default GC configuration
  features/image/java/gc.feature:12  Check GC_MIN_HEAP_FREE_RATIO GC configuration
  features/image/java/gc.feature:19  Check GC_MAX_HEAP_FREE_RATIO GC configuration
  features/image/java/gc.feature:26  Check GC_TIME_RATIO GC configuration
  features/image/java/gc.feature:33  Check GC_ADAPTIVE_SIZE_POLICY_WEIGHT GC configuration
  features/image/java/gc.feature:40  Check GC_MAX_METASPACE_SIZE GC configuration
  features/image/java/gc.feature:47  Check GC_CONTAINER_OPTIONS configuration
  features/image/java/java_s2i.feature:11  run the s2i and check the maven mirror and proxy have been initialised in the default settings.xml, uses http_proxy
  features/image/java/java_s2i.feature:24  run the s2i and check the maven mirror, proxy (including username and password) and non proxy have been initialised in the default settings.xml, uses http_proxy
  features/image/java/java_s2i.feature:36  run the s2i and check the maven mirror, proxy (including username) and non proxy have been initialised in the default settings.xml, uses http_proxy
  features/image/java/java_s2i.feature:47  run the s2i and check the maven mirror and proxy have been initialised in the default settings.xml, uses HTTP_PROXY
  features/image/java/java_s2i.feature:60  run the s2i and check the maven mirror, proxy (including username and password) and non proxy have been initialised in the default settings.xml, uses HTTP_PROXY
  features/image/java/java_s2i.feature:72  run the s2i and check the maven mirror, proxy (including username) and non proxy have been initialised in the default settings.xml, uses HTTP_PROXY
  features/image/java/java_s2i.feature:83  run the s2i and check the maven mirror and proxy have been initialised in the default settings.xml, uses http_proxy and HTTP_PROXY
  features/image/java/java_s2i.feature:97  run the s2i and check the maven mirror, proxy (including username and password) and non proxy have been initialised in the default settings.xml, uses http_proxy and HTTP_PROXY
  features/image/java/java_s2i.feature:110  run the s2i and check the maven mirror, proxy (including username) and non proxy have been initialised in the default settings.xml, uses http_proxy and HTTP_PROXY
  features/image/java/java_s2i.feature:122  run the s2i and check the maven mirror and proxy have been initialised in the default settings.xml, uses https_proxy
  features/image/java/java_s2i.feature:135  run the s2i and check the maven mirror, proxy (including username and password) and non proxy have been initialised in the default settings.xml, uses https_proxy
  features/image/java/java_s2i.feature:147  run the s2i and check the maven mirror, proxy (including username) and non proxy have been initialised in the default settings.xml, uses https_proxy
  features/image/java/java_s2i.feature:158  run the s2i and check the maven mirror and proxy have been initialised in the default settings.xml, uses HTTPS_PROXY
  features/image/java/java_s2i.feature:171  run the s2i and check the maven mirror, proxy (including username and password) and non proxy have been initialised in the default settings.xml, uses HTTPS_PROXY
  features/image/java/java_s2i.feature:183  run the s2i and check the maven mirror, proxy (including username) and non proxy have been initialised in the default settings.xml, uses HTTPS_PROXY
  features/image/java/java_s2i.feature:194  run the s2i and check the maven mirror and proxy have been initialised in the default settings.xml, uses https_proxy and HTTPS_PROXY
  features/image/java/java_s2i.feature:208  run the s2i and check the maven mirror, proxy (including username and password) and non proxy have been initialised in the default settings.xml, uses https_proxy and HTTPS_PROXY
  features/image/java/java_s2i.feature:221  run the s2i and check the maven mirror, proxy (including username) and non proxy have been initialised in the default settings.xml, uses https_proxy and HTTPS_PROXY
  features/image/java/java_s2i.feature:233  run the s2i and check the maven mirror, proxy (including username and password) and non proxy have been initialised in the default settings.xml, uses https_proxy and HTTPS_PROXY
  features/image/java/java_s2i.feature:246  run s2i assemble and check HTTP_PROXY_NONPROXYHOSTS is honoured
  features/image/java/java_s2i.feature:258  run s2i assemble and check HTTP_PROXY_NONPROXYHOSTS is honoured with multiple entries
  features/image/java/java_s2i.feature:270  run an S2I build that depends on com.redhat.xpaas.repo.redhatga being defined
  features/image/java/java_s2i.feature:278  Ensure legacy ARTIFACT_COPY_ARGS works as it used to
  features/image/java/java_s2i.feature:286  Test that maven is executed in batch mode
  features/image/java/java_s2i_inc.feature:8  Check incremental builds cache .m2
  features/image/java/ports.feature:7  Check ports are available
  features/image/java/runtime.feature:7  Ensure JVM_ARGS is no longer present in the run script
  features/image/java/runtime.feature:15  Ensure JAVA_ARGS are passed through to the running java application
  features/image/java/runtime.feature:25  Ensure diagnostic options work correctly

Do you know why?

Originally posted by @jerboaa in #172 (comment)

The environment variable MAVEN_OPTS influences S2I/maven behaviour, but is not documented as a user-tweakable environment variable.

Since @bmcelvee has reviewed text that originated in the YAML files from the container image sources, I'll make sure we feed back the improvements to there. Thanks!

Originally posted by @jmtd in openshift/openshift-docs#32543 (comment)

While working on quarkusio/quarkus-quickstarts#81, I hit:

WARN ARTIFACT_COPY_ARGS is deprecated.  Please use S2I_SOURCE_DEPLOYMENTS_FILTER to specify artifact types and MAVEN_S2I_ARTIFACT_DIRS to specify the build output directories to copy from.

When looking at this repo for doc (something like this doc over here) I could not find any list of supported environment variables with explanations.

The "product" documentation, which is based on this community project, does not seem to have such documentation either?

Googling let me find https://github.com/jboss-openshift/cct_module/blob/master/jboss/container/s2i/core/api/README.adoc and https://github.com/jboss-openshift/cct_module/tree/master/jboss/container/maven/s2i/api but, to an end-user, it is not clear how those module docs in separate repos relate to this project (and what other ones there are).

Perhaps we could improve the README? Either with appropriate links, or copy/paste.

@tqvarnst @siamaksade

The runtime images should have their com.redhat.component label altered so that -runtime is added after the JDK major version, e.g., openjdk-8-ubi8-container => openjdk-8-runtime-ubi8-container.

We need to add entries for OpenJDK 17 to the following template files in templates/:

"community-image-streams.json"
"image-streams-aarch64.json"
"image-streams.json"
"image-streams-ppc64le.json"
"image-streams-s390x.json"
"openjdk-web-basic-s2i.json"
"openjdk-web-basic-s2i.json.orig"
"runtime-image-streams.json"

These changes need to target the release branch, in order for the scripts in https://github.com/openshift/library to pull in the changes.
The changed files can be tested by

1. syntax checking by running through a tool like jq,
2. importing them into an OpenShift cluster,
3. running the make import, make verify steps from a clone of https://github.com/openshift/library which has been adjusted to pull the templates from a development fork/branch.

new issue to continue the discussion started in the now closed #56 ...

The full-fat builder images container run scripts (related to S2I) which are set to run when the container starts up via the container CMD (ref).

We are not installing run scripts into the runtime images (Yet. We might in the future). We need to consider what the container CMD should be set to. At the moment I think we inherit the base image CMD (which is just /bin/bash), but running the container results in nothing (at least for me)

We could consider a run CMD that invoked java, but what arguments should we pass to it?

we should enable including the generated help.md from this cekit feature
https://cekit.readthedocs.io/en/latest/image_help_pages.html

Hello - we have a issue that .java_pid is missing in /tmp/ but we need this because of instana will serve metrics ect. from the jvm with this file - can someone explain why it is missing or what we can do to enable this file ?

Now they we have transitioned away from the develop/release model, where we only do builds and release, and are now doing builds from develop, I think we should add a “main” branch (same commits as develop) as a new default branch and plan to delete release and develop (and the older branches from before even then)

I am creating my own image from registry.access.redhat.com/ubi8/openjdk-11-runtime
I notice that the JAVA_HOME env variable points to /usr/lib/jvm/java-11 (https://github.com/jboss-container-images/openjdk/blob/develop/modules/jre/11/module.yaml#L17) that doesn't exist in the image.

We could improve the README of this project... I'll outline a possible future structure, for discussion.

We need to figure out and write down:

• How to file issues?
• Where to file issues?
• What requirements needs to be met to merge a PR?
• What is the release workflow?

We use an external content_sets file for the RHEL7 images and embedded into the image (override) YAML for RHEL8 images. We should probably pick one approach and use it consistently. I think I prefer embedding in the override yaml. If we instead choose the file approach, we should rename content_sets.yaml to reflect it only being applicable for the RHEL7 images.

from #48:

Note, using this method, the files in the image will still be named with -redhat- in them, but they will be the community versions (you can verify by expanding the jars and looking at the META-INF/maven/... files).

@jmtd, if we're going to make the default versions of the image.yaml file community oriented, we should probably do the same with the upstream modules (jolokia, hawkular, jmx_exporter). That said, there's probably some work to be done in cekit to help ensure we're using the "proper" file names for these types of resources (e.g. jolokia-jvm-1.5.0-agent.jar instead of jolokia-jvm-1.5.0.redhat-1-agent.jar). @goldmann, @dbecvarik, you're probably interested in this as well, from a cekit perspective.

from #58 :

Putting this in these image sources here would be a short-term solution, because the problem is really over in cct_modules, where the artefact definitions are (e.g. https://github.com/jboss-openshift/cct_module/blob/master/jboss/container/jolokia/bash/module.yaml), as @rcernich says in #48 , we probably need community variants of the modules that are pulled in by this image, with correct checksums for the community versions.

I'm not familiar enough with Cekit to be able to help with that hands-on myself... 😄

Just sayin' to avoid anyone thinking that I'll do this.

While working on quarkusio/quarkus-quickstarts#81, I'm using:

ARTIFACT_COPY_ARGS=-p -r lib/ *-runner.jar

seeing this:

WARN ARTIFACT_COPY_ARGS is deprecated.  Please use S2I_SOURCE_DEPLOYMENTS_FILTER to specify artifact types and MAVEN_S2I_ARTIFACT_DIRS to specify the build output directories to copy from.

I've therefore attempted to use S2I_SOURCE_DEPLOYMENTS_FILTER instead of ARTIFACT_COPY_ARGS like this:

S2I_SOURCE_DEPLOYMENTS_FILTER=*-runner.jar lib/*.jar

as, according to https://github.com/jboss-openshift/cct_module/blob/master/jboss/container/s2i/core/api/README.adoc (which is somewhat hard to find BTW, see #74), it's a "Space separated list of filters to be applied when copying deployments." ...

INFO Copying deployments from target to /deployments...
'/tmp/src/target/quarkus-quickstart-1.0-SNAPSHOT-runner.jar' -> '/deployments/quarkus-quickstart-1.0-SNAPSHOT-runner.jar'
Build completed successfully

... but this does not work. Upon investigating this, I found that it does not actually copy the lib/*.jar (only *-runner.jar) - I'm guessing that S2I_SOURCE_DEPLOYMENTS_FILTER does not support sub-directories? It should.

@jmtd @goldmann @rcernich @wdecoste

PS: I'm filing this issue here in this project instead of over in https://github.com/jboss-openshift/cct_module (where S2I_SOURCE_DEPLOYMENTS_FILTER seems to actually be implemented) because that project disabled Issues (without any indication its README where to file issues for that project).

For #51 I've played with a first test, and it failed when it tried to GET /metrics ...

I was just wondering if this was expected in this image?

Inside a chained build, I was expecting to only have to copy a bootable JAR into the runtime image /deployments directory then have the run script to take over on image run and start my app with correct JVM settings.
Instead it is displaying the message: "This is the Red Hat UBI8 OpenJDK 11 Runtime container".
I am wandering if the runtime image could take advantages of the automatic (and configurable) JVM configuration we find in the builder image and offer an entry point that would automatically run/configure a java application?
Thank-you.

The released images I could find are jdk 11. AFAICT the newer ubi8-based builders are also based on jdk 11. Is it possible to use a newer jdk?

according to https://cekit.readthedocs.io/en/develop/test.html, cekit test should test this project? NOK:

$ sudo dnf install python3-behave
$ cekit test                     
2019-02-13 04:58:49,862 cekit        INFO     Generating files for docker engine.
2019-02-13 04:58:49,872 cekit        INFO     Initializing image descriptor...
2019-02-13 04:58:49,873 cekit        INFO     Preparing resource 'cct_module'
2019-02-13 04:58:50,708 cekit        WARNING  The way of defining repository 'jboss-os' is deprecated. Convert it to an URL based repository object. Consult Cekit docs, for more details.
2019-02-13 04:58:50,941 cekit        INFO     Fetching common steps from 'https://github.com/cekit/behave-test-steps.git'.
2019-02-13 04:58:51,441 cekit        INFO     Tests collected!
Exception ModuleNotFoundError: No module named 'lxml'
2019-02-13 04:58:51,615 cekit        ERROR    An error occurred while executing tests
2019-02-13 04:58:51,615 - cekit - ERROR - An error occurred while executing tests

I'm guessing I'm missing whatever lxml is... cekit/cekit#381 would be cool.