Bug 1761925 - Cluster Loader fails when called without configuration [NEEDINFO]
Summary: Cluster Loader fails when called without configuration
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Cluster Loader
Version: 4.2.0
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
: 4.3.0
Assignee: Sebastian Jug
QA Contact: Walid A.
URL:
Whiteboard:
Depends On:
Blocks: 1765249
TreeView+ depends on / blocked
 
Reported: 2019-10-15 15:27 UTC by Sebastian Jug
Modified: 2020-10-01 07:17 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-01-23 11:07:48 UTC
Target Upstream Version:
sychen: needinfo? (sejug)


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github openshift origin pull 23994 'None' closed Bug 1761925: CL fix fixture path & update config path, quickstarts & bindata 2020-11-16 19:35:25 UTC
Red Hat Bugzilla 1817620 high CLOSED [doc] a different registry for the Cluster Loader 2020-10-14 00:28:05 UTC
Red Hat Product Errata RHBA-2020:0062 None None None 2020-01-23 11:08:15 UTC

Description Sebastian Jug 2019-10-15 15:27:39 UTC
Description of problem:
Cluster Loader is a scale test tool (https://docs.openshift.com/container-platform/4.1/scalability_and_performance/using-cluster-loader.html#running_cluster_loader_)

When running it without specifying user provided configuration, it does not successfully locate the built in test templates.


Version-Release number of selected component (if applicable):
4.2


How reproducible:
Always


Steps to Reproduce:
1.sudo podman run -v ${LOCAL_KUBECONFIG}:/root/.kube/config -i
quay.io/openshift/origin-tests:4.1 /bin/bash -c 'export KUBECONFIG=/root/.kube/config && openshift-tests run-test "[Feature:Performance][Serial][Slow] Load cluster should load the cluster [Suite:openshift]"'
2. Fail


Actual results:
Error stating unable to find template files in built in config.


Expected results:
Succesful execution of built in config by deploying test data templates.


Additional info:

Comment 2 Sebastian Jug 2019-10-16 14:13:36 UTC
[jugs@trip ~]$ sudo podman run -v /home/jugs/.kube/config:/root/.kube/config:z -i quay.io/openshift/origin-tests:4.2 /bin/bash -c 'export KUBECONFIG=/root/.kube/config && \
openshift-tests run-test "[Feature:Performance][Serial][Slow] Load cluster should load the \
cluster [Suite:openshift]"'
I1016 14:13:00.006474       7 test.go:182] openshift-tests excluded test regex is "\\[Disabled:|\\[Disruptive\\]|\\[Skipped\\]|\\[Slow\\]|\\[Flaky\\]|\\[local\\]|\\[Suite:openshift/test-cmd\\]|\\[Skipped:skeleton\\]|\\[Skipped:Network/OpenShiftSDN\\]"
Oct 16 14:13:00.134: INFO: >>> kubeConfig: /root/.kube/config
Oct 16 14:13:00.137: INFO: Waiting up to 30m0s for all (but 100) nodes to be schedulable
Oct 16 14:13:01.045: INFO: Waiting up to 10m0s for all pods (need at least 0) in namespace 'kube-system' to be running and ready
Oct 16 14:13:01.316: INFO: 0 / 0 pods in namespace 'kube-system' are running and ready (0 seconds elapsed)
Oct 16 14:13:01.316: INFO: expected 0 pod replicas in namespace 'kube-system', 0 are Running and Ready.
Oct 16 14:13:01.316: INFO: Waiting up to 5m0s for all daemonsets in namespace 'kube-system' to start
Oct 16 14:13:01.405: INFO: e2e test version: v1.14.6+bad6c07
Oct 16 14:13:01.487: INFO: kube-apiserver version: v1.14.6+bebfa64
[BeforeEach] [Top Level]
  /go/src/github.com/openshift/origin/_output/local/go/src/github.com/openshift/origin/test/extended/util/test.go:59
[BeforeEach] [Feature:Performance][Serial][Slow] Load cluster
  /go/src/github.com/openshift/origin/_output/local/go/src/github.com/openshift/origin/vendor/k8s.io/kubernetes/test/e2e/framework/framework.go:149
STEP: Creating a kubernetes client
Oct 16 14:13:01.488: INFO: >>> kubeConfig: /root/.kube/config
[BeforeEach] [Feature:Performance][Serial][Slow] Load cluster
  /go/src/github.com/openshift/origin/_output/local/go/src/github.com/openshift/origin/test/extended/cluster/cl.go:44
Oct 16 14:13:01.494: INFO: Undefined config file, using built-in config /tmp/fixture-testdata-dir318529024/test/extended/testdata/cluster/master-vert.yaml

[It] should load the cluster [Suite:openshift]
  /go/src/github.com/openshift/origin/_output/local/go/src/github.com/openshift/origin/test/extended/cluster/cl.go:65
Oct 16 14:13:01.495: INFO: Our tuning set is: &{default {{5 0s 0s} {0s}} {{0 0s 0s} {0s}}}
Oct 16 14:13:01.585: INFO: Project clusterloader-cakephp-mysql0 does not exist.
Oct 16 14:13:01.585: INFO: Configuration requested deletion of project clusterloader-cakephp-mysql0
Oct 16 14:13:01.585: INFO: Running 'oc --namespace= --config= adm new-project clusterloader-cakephp-mysql0'
Created project clusterloader-cakephp-mysql0
Oct 16 14:13:02.249: INFO: 1/1 : Created new namespace: clusterloader-cakephp-mysql0
[AfterEach] [Feature:Performance][Serial][Slow] Load cluster
  /go/src/github.com/openshift/origin/_output/local/go/src/github.com/openshift/origin/test/extended/util/client.go:120
[AfterEach] [Feature:Performance][Serial][Slow] Load cluster
  /go/src/github.com/openshift/origin/_output/local/go/src/github.com/openshift/origin/vendor/k8s.io/kubernetes/test/e2e/framework/framework.go:150
Oct 16 14:13:02.252: INFO: Waiting up to 3m0s for all (but 100) nodes to be ready
Oct 16 14:13:02.505: INFO: Running AfterSuite actions on all nodes
Oct 16 14:13:02.505: INFO: Running AfterSuite actions on node 1
fail [github.com/openshift/origin/test/extended/cluster/cl.go:156]: Unexpected error:
    <*errors.errorString | 0xc00281f110>: {
        s: "unable to find pod/template file ./test/extended/testdata/cluster/quickstarts/cakephp-mysql.json\n",
    }
    unable to find pod/template file ./test/extended/testdata/cluster/quickstarts/cakephp-mysql.json

occurred

Comment 3 Sebastian Jug 2019-10-16 15:43:48 UTC
It seems that the change in origin:
https://github.com/openshift/origin/blob/master/vendor/k8s.io/kubernetes/test/e2e/patch_from_e2e_testfile.go#L61

Neuters the function that we were using to find the viperConfig path, now always returning "" rather than the path.
Will need to work around this in the Cluster Loader test.

Comment 5 Sebastian Jug 2019-10-18 12:26:50 UTC
Cluster Loader is part of extended test and has no component of its own

Comment 7 Sebastian Jug 2019-10-20 18:47:57 UTC
Fixed in https://github.com/openshift/origin/pull/23994

Comment 11 Sebastian Jug 2019-11-25 15:16:53 UTC
The docs will need to be updated as the openshift-tests have moved from quay.io/openshift/origin-tests:4.3 to the new repo: registry.svc.ci.openshift.org/ocp/4.3:tests

Comment 12 Siva Reddy 2019-11-25 16:14:49 UTC
Cluster loader is now able to find the default config when there is no config specified.

Note: the image to get the openshift-tests is "registry.svc.ci.openshift.org/ocp/4.3:tests" and not "quay.io/openshift/origin-tests:4.3"

Steps to Verify:
1. pull the openshift tests from the "registry.svc.ci.openshift.org/ocp/4.3:tests"
    podman pull registry.svc.ci.openshift.org/ocp/4.3:tests
2. Run the tests with out specifying a config.
    sudo podman run -v ${LOCAL_KUBECONFIG}:/root/.kube/config:z -i registry.svc.ci.opensh
ift.org/ocp/4.3:tests /bin/bash -c 'export KUBECONFIG=/root/.kube/config && openshift-tests run-test "[Feature:Performance][Serial][Slow
] Load cluster should load the cluster [Suite:openshift]"'
3. Note that the cluster loader doesn't fail with the error "unable to find pod/template file ./test/extended/testdata/cluster/quickstarts/cakephp-mysql.json" but it successfully creates projects with different templates.
4. # oc projects | grep clusterloader
    clusterloader-cakephp-mysql0
    clusterloader-dancer-mysql0
    clusterloader-django-postgresql0
    clusterloader-nodejs-mongodb0
    clusterloader-rails-postgresql0

Comment 13 Ashley Hardin 2020-01-14 19:19:01 UTC
Documentation updates: https://github.com/openshift/openshift-docs/pull/18293

Comment 15 errata-xmlrpc 2020-01-23 11:07:48 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:0062


Note You need to log in before you can comment on or make changes to this bug.