operator-framework-junit-5 version 4.4.0 doesn't work with fabric8 version 6.8.0

[bachmanity1]

Bug Report

I'm using josdk version 4.4.0 with fabric8 version 6.8.0 overall everything works as expected except for e2e tests. Running e2e tests gives this error:

I think this is related to the fact that josdk v4.4.0 internally depends on fabric8 v6.7.2. I'm not sure why this problem happens because my project has a direct dependency on fabric8 and I thought all transitive dependencies will use version specified by the direct dependency.

Here is relevant part of the dependency tree:

.

@csviri I think to reproduce this problem you should edit pom file of example operators to use fabric8 v6.8.0 and josdk v.4.4.0.

The problem is resolved when I run mvn install -Dmaven.test.skip=true using branch fabric-6.8 and use version 4.4.1-SNAPSHOT in my project. So, maybe I just should wait for the release of next version.

What did you do?

What did you expect to see?

What did you see instead? Under which circumstances?

Environment

Kubernetes cluster type:

$ Mention java-operator-sdk version from pom.xml file

$ java -version

$ kubectl version

Possible Solution

Additional context

[csviri]

The error happens in the Junit extension, the thing is that it not happens for the internal ITs at least when the client is upgraded:
#1975

If you could create/opensource a sample to reproduce that would be a big help

[bachmanity1]

If you could create/opensource a sample to reproduce that would be a big help

I think to reproduce this error you could just use any of the sample operators under sample-operators directory, just make sure that pom file uses josdk version 4.4.0 and fabric8 version 6.8.0 and then try to run the e2e test.

[csviri]

As you can see this build passes, that uses those version: https://github.com/operator-framework/java-operator-sdk/pull/1975/files
All the samples have end to end tests using that junit extension, and it does not fail at all.

[bachmanity1]

As you can see this build passes, that uses those version: https://github.com/operator-framework/java-operator-sdk/pull/1975/files All the samples have end to end tests using that junit extension, and it does not fail at all.

yes, I saw that but I don't think that's what I'm trying to tell you.
In the e2e tests mentioned by you, josdk has an internal dependency on f8 version 6.8.0 but to reproduce this bug it should have internal dependency on versioin 6.7.2 and sample operator should have direct dependency on version 6.8.0.

[csviri]

Yes, but that we don't support, so out of the box what is supported is the fabric8 client version comes with the framework. We will release new version with v6.8.0 soonish (will see based also on Quarkus side).

If you provide a minimalist example, I can still take a quick look to help with that..

[bachmanity1]

@csviri I've added a simple example that reproduces this error.
https://github.com/bachmanity1/josdk-test

[csviri]

I added a PR:

changing usage of builder from:

     new NamespaceBuilder()
               .withNewMetadata().withName(namespace).endMetadata()
               .build()

to:

new NamespaceBuilder().withMetadata(
                    new ObjectMetaBuilder()
                            .withName(namespace)
                            .build())
                .build())

That seems to be fixing this problem.

tbh I still not fully understand why this happens, and certainly not happens in the tests.

@manusa @shawkins might be interested.

[manusa]

If I'm understand correctly this might happen when mixing different Fabric8 Kubernetes Client versions (more specifically 6.7.2 and 6.8.0) but it's not reproducible when the Operator is directly using 6.8.0, right?

The problem might be explained through the changes in sundrio and the removal/refactor of the Fluent interface. So probably the nested buildables are incompatible.

If it does happen when the client is only 6.8.0, then we might have a big problem. However, I haven't seen this behavior reproduced elsewhere and it does seem to be a simple and common use case.

[csviri]

If I'm understand correctly this might happen when mixing different Fabric8 Kubernetes Client versions (more specifically 6.7.2 and 6.8.0) but it's not reproducible when the Operator is directly using 6.8.0, right?

no, or at least no in our samples

[shawkins]

If it does happen when the client is only 6.8.0, then we might have a big problem.

I can confirm it does not.

So probably the nested buildables are incompatible.

It's hard wrap my head around what would be happening here - all of the relevant classes would be coming from a single jar
kubernetes-model-core, that would have the model objects, the sundrio package, and the generated annotation classes.

[manusa]

It's hard wrap my head around what would be happening here - all of the relevant classes would be coming from a single jar
kubernetes-model-core, that would have the model objects, the sundrio package, and the generated annotation classes.

I only trust maven-enforcer-plugin for that :)

Although it's not exactly the same, I do see similar problems when mixing buildables created from different sundrio versions in this PR: dekorateio/dekorate#1233 (check description bullet point 1).

[shawkins]

@csviri are you sure about committing this fix? It seems like if this were happening for the namespace builder it could happen all of the place with mixing versions.