Skip to content
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

TEST_NAME is not supported in k8s_scale.sh #261

Open
marcemq opened this issue Nov 1, 2019 · 3 comments
Open

TEST_NAME is not supported in k8s_scale.sh #261

marcemq opened this issue Nov 1, 2019 · 3 comments

Comments

@marcemq
Copy link
Contributor

marcemq commented Nov 1, 2019

What
From k8s_scale.sh help, it is stated that TEST_NAME can be set to over-ride the default JSON results filename, which is not true:

$ ./k8s_scale.sh -h
Usage: ./scaling/k8s_scale.sh [-h] [options]
   Description:
        Launch a series of workloads and take memory metric measurements after
        each launch.
   Options:
                -h,    Help page.

Environment variables:
        Name (default)
                Description
        TEST_NAME (k8s scaling)
                Can be set to over-ride the default JSON results filename
        NUM_PODS (20)
                Number of pods to launch
        STEP (1)
                Number of pods to launch per cycle
        wait_time (30)
                Seconds to wait for pods to become ready
        delete_wait_time (600)
                Seconds to wait for all pods to be deleted
        settle_time (5)
                Seconds to wait after pods ready before taking measurements
        use_api (yes)
                specify yes or no to use the API to launch pods
        grace (30)
                specify the grace period in seconds for workload pod termination

When attempting to use such variable the result JSON file name is still k8s-scaling.json

$ TEST_NAME=my_lovely_test ./k8s_scale.sh
INFO: Initialising
command: bc: yes
command: jq: yes
INFO: Checking Kubernetes accessible
...
All pods have terminated at cycle 48
INFO: Delete Took 49661 ms (1572631645940456173 - 1572631596278977403)
cleaning up kubectl proxy

$ tree results/
results/
└── k8s-scaling.json

0 directories, 2 files

And the k8s_parallel.sh, k8s_scale_nc and k8s_scale_rapid might have the same behaviour.

@grahamwhaley
Copy link

:-) - you are right, it looks like at some point during development that feature got 'lost'. It should be implemented something like the kata code does at https://github.com/kata-containers/tests/blob/master/metrics/density/fast_footprint.sh#L98 , so:

TEST_NAME="${TEST_NAME:-k8s scaling}"

or similar.
If you are fixing that one - can you fix all the other tests as well please? :-)

Note btw, be aware that if you change the name of the test, then the name of the results .json file will change (which is what you may intend), but, that means that the R pdf report generator may not then find that file to process. That is sort of deliberate. Changing the names of the results files can be very useful for hand examining or scripting many runs, but, may not then work with the automated report generation.

@askervin
Copy link
Contributor

askervin commented Nov 5, 2019

@marcemq, @grahamwhaley , do you think we could use TEST_NAME so that test scripts would save their output files directly under results/TEST_NAME subdirectory?

That is, every test script would create separate json file (k8s-scaling.json, k8s-scaling-nc.json, ...) like today - which is very handy for R pdf report generation. But after the change the user would not need to manually create the results/TEST_NAME subdirectory and move most recent json files there anymore.

@grahamwhaley
Copy link

@askervin - given how we predominantly run the tests today, yes, that is probably a sensible thing to do. Originally the data was consumed by CIs, so the subdirs were not necessary - but now it is mostly a human driven thing with the R scripts, it makes sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants