-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PoC for Kubernetes provisioning support (via OLM) #206
Conversation
b6fb8df
to
4298e0d
Compare
4298e0d
to
5ea23c2
Compare
a505dff
to
788a78c
Compare
new HyperfoilOperatorApplication() { | ||
@Override | ||
public Hyperfoil getHyperfoil() { | ||
Hyperfoil hyperfoil = new HyperfoilBuilder( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this could return directly without using a local variable as in HyperfoilOpenShiftOperatorProvisionerTest
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
} | ||
|
||
@Override | ||
public TargetType getTarget() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
couldn't this be deduced from execution context? I am assuming we run against K8 OR OCP, not the two at the same time in the same test run
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Intersmash uses ProvisionerFactory
instances to dynamically select the relevant provisioner for an Application, i.e. the Application type drives the decision, and this is the logic that we want to build upon.
That being said I changed the implementation in the last push so that there is no longer need for the implementing Application instance to set an enum value, but just to additionally implement either OpenShiftApplication
or KubernetesApplication
IIUC what you are relating to, is the ability for a test suite that uses Intersmash to execute a set of tests just against K8s or OpenShift in one single run. This is something that must be implemented in the domain of the client test suite, and not by Intersmash. We actually do something similar in the Intersmash testsuite, where we use the OpenShiftTest
or KubernetesTest
categories to select which tests should be run.
|
||
@TestMethodOrder(MethodOrderer.OrderAnnotation.class) | ||
@KubernetesTest | ||
public class HyperfoilKubernetesOperatorProvisionerTest implements NamespaceCreationCapable { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
couldn't we use a single interface and deduce if K8 OR OCP from some context? I am assuming we run against K8 OR OCP, not the two at the same time in the same test run
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mean for Project
vs. Namespace
creation?
Tests are meant to be different, depending on whether they would target Kubernetes or OpenShift, and such detail (i.e. whether to create a Namespace or a Project), is one of the details that should be set explicitly to decouple the provisioning functionality from the execution context.
The same applies if you're relating to K8s vs. OpenShift tests. In fact, it is very likely that different resources or processes would be verified, depending on the target platform.
Of course there could also be the chance that K8s or OpenShift scenarios and tests could be similar, but this should not break the original requirement to be able and deploy/tests on both the platforms.
IIUC what you are relating to, is the ability for a test suite that uses Intersmash to execute a set of tests just against K8s or OpenShift in one single run. This is something that must be implemented in the domain of the client test suite, and not by Intersmash. We actually do something similar in the Intersmash testsuite, where we use the OpenShiftTest
or KubernetesTest
categories to select which tests should be run.
/test |
b0eb8af
to
2045dc9
Compare
f49be5e
to
d88eabe
Compare
…nShift/Kubernetes JUnit5 extension behavior
Thanks for the initial review comments, @tommaso-borgato Regarding the CI checks, we are now green on Kubernetes, as you can see from the CI checks, but I am still fixing the OpenShift ones. |
51ecc38
to
78a9a0e
Compare
/test |
Intersmash PR CI check resultsHi @fabiobrz, this comment is meant to report the outcome of Intersmash integration tests, CI checks job <continuous-testing-umb-listener-for-intersmash-pr-checks#145> FAILED:
|
<eap-8.x-intersmash-integration-tests-products-jboss-eap#84> reported 1 failure:
which is an unrelated random issue, reported as fixed by the subsequent run: <eap-8.x-intersmash-integration-tests-products-jboss-eap#85> ✅
<eap-8.x-intersmash-integration-tests-products-jboss-eap-xp#93> was actually a failed build, restarted as <eap-8.x-intersmash-integration-tests-products-jboss-eap-xp#94>, where we had only 1 failure:
which is an intermittent one, due to cluster instability. ✅ Based on the above findings, the changes in the PR are deemed to pass the integration tests and can now be reviewed. |
…es in order to introduce Olm based provisioning, and generic operator provisioners. Also fixing the testsuite modules accordingly
78a9a0e
to
a02967e
Compare
… order to set the XP GA bits version
…r in order to use the new MAVEN_S2I_ARTIFACT_DIRS s2i env var, see https://issues.redhat.com/browse/WFWIP-667
a02967e
to
e3537fe
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, I just asked one question ....
@@ -1,2 +1 @@ | |||
cz.xtf.junit5.listeners.TestExecutionLogger | |||
cz.xtf.junit5.listeners.ProjectCreator |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@fabiobrz I didn't understand why we had to introduce it here ... I believed openshift project creation was already taken care ....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your question @tommaso-borgato
I removed the class from the SPI registration because we can only use it for tests that are expected to run on OpenShift.
Previously we had it in here because we knew we were running only on OpenShift, and project creation was expected to happen anyway.
This is why now we let specific tests implement the two different interfaces for project (OCP) or namespace (k8s) creation.
Description
Resolves #133
Additional issues which are solved by this PR:
Since the changes are broadly impacting the codebase, some issues have been fixed along the ways, ideally in separated commits:
Type of change
test, version modification, documentation, etc.)
Checklist