Experiments with CAMP in CityGo use case: different issues

[jesus-gorronogoitia]

Characteristics

• Issue Type: bug|report|ask for support
• Reproducibility: always
• Severity: major
• Tool/Service/Component: CAMP v0,2
• Execution Environment: Linux Thumbleweed
• Reporter: Jesús Gorroñogoitia [email protected]

Description

I've followed the CAMP documentation for CityGo use case. Everything goes well and CAMP generates 10 configurations.
Questions:
1- I always get 10 configurations generated, regardless the CAMP command I issue:
camp generate -d . --all
or
camp generate -d . --coverage

Is there a configuration to ask CAMP to generate a number of configurations (or at least up to that number)?
2- Where can we described in the camp.yml file the location of the input docker-compose.yml file?
Is this one by default: ./template/docker-compose.yml?

Bugs:
1- To generate the images, I issue the build_images.sh script generated by CAMP in the out/config_X folder, but I get the exception:

yosu@avalon:~/Projects/STAMP/Git/camp/samples/stamp/atos/out/config_1/images> sh ./build_images.sh 
"docker build" requires exactly 1 argument.
See 'docker build --help'.

Usage:  docker build [OPTIONS] PATH | URL | -

Build an image from a Dockerfile
"docker build" requires exactly 1 argument.
See 'docker build --help'.

Usage:  docker build [OPTIONS] PATH | URL | -

Build an image from a Dockerfile
All images ready.

I think the script is missing the path . at the end of each docker build line, so it should be:
docker build -t camp-postgres_0 -f ./postgres_0/Dockerfile .
instead of
docker build -t camp-postgres_0 -f ./postgres_0/Dockerfile

2- Once I fix this, and run the docker build, I get an building error:

Step 13/18 : ADD init-db.sql $DIR_DB
ADD failed: stat /home/docker/tmp/docker-builder408682663/init-db.sql: no such file or directory

I will investigate this from my side.

Steps to reproduce

Other files and URLs

Relationships

Help on issue template

Preview to follow the link or open file .github/ISSUE_DOC.md

[fchauvel]

Thanks for the feedback. I answer your questions below:

1. As for the number of configurations generated, there is not yet a option to set the maximum number of configuration that CAMP generates. Note that this would only be relevant for the --all version, as I see a conflict between the number of configuration and the capacity to cover all single variations. I don't know if there are more than 10 configurations that are possible in the CityGo use case. I have to check this by hand and come back to you, but from the top of my hand, this looks like a bug :-)

2. The docker-compose file is expected to be at the root of the template folder. I take not that it may be useful to define these settings.

3. @brice-morin just reported the issue on the build_images.sh and I am working on it (see Issue Generated build_images.sh do not work with newer versions of Docker #23).

4. As for the error when building the Docker images, I will investigate this asap.

[fchauvel]

I just pushed a fix for Issue #23, so you may want to try with the docker images fchauvel/camp:dev, and let me know.

As for the error, when building the images I think the template directory misses many files that the Dockerfile refer to. I'm looking into other branches of the CAMP repositories but I haven't found them yet.

As for the option to limit the number of generated configurations, I just saw you already requested it Issue #14. I schedule this for the v0.3

[fchauvel]

As for the fact that the number of configuration is the same when running with coverage or for all configurations, I think it results from the constraints that are set. I details how the constraints unfold at the end.
Here all variables are declared to the same component, and the values of variables depends on each other. This implies that all configurations are needed to cover all single variations.

There are three variables:

• thread_limit, which is either 64 or 128
• thread_per_child, which ranges from 0 to 128, with a maximum coverage of 10. The actual values are therefore [0, 8, 16, 32, 40, 48, 56, 64, 72, 80, 88, 96, 104, 112, 120, 128].
• max_request_worker which is not bounded.

There are the following constraints:

1. thread_limit > thread_per_child
2. thread_per_child * 16 = max_request_worker
3. (thread_per_child >= 100 and max_request_worker >= 200) or (thread_limit <= 64 and max_request_worker >= 2)

From Constraint 1 and the second part of Constraint 3, we know that thread_per_childmust be lower than thread_per_child, and therefore strictly lower than 64. This reduces its possible values to the range [0, 56]. From Constraint 2, max_request_worker must be above 2, and also equals 16 * thread_per_child, which rules out the value 0, leaving us with the range [8, 56].

From the first part of Constraint 1, we know that thread_per_child must be above 100, which adds up the range [104, 112, 120, 128]. But from Constraint 1, thread_per_child must strictly below thread_limit, which invalidate value 128.

We are left with 10 possible values for thread_per_child that are [8, 16, 24, 32, 40, 48, 56, 104, 112, 120]. In addition, we need one configuration to test every single value, so we need 10 configurations.

[fchauvel]

Have you got any progress on the CityGo case? Can we help?

[jesus-gorronogoitia]

Hi @fchauvel Yes, I completed the experimentation, thank you so much for your support. Your CAMP documentation is real awesome!
I generated the configurations using CAMP and injected them into our CI for instantiate CityGo and run stress tests. Everything has been reported in D5.6

[fchauvel]

That's great!

If I may ask, would it be possible for you to share the missing files of the CityGo case-study, so that the repository is complete and other people can run it? I definitely understand if there are IPR constraints that prevent that, though.

[jesus-gorronogoitia]

Hi @fchauvel Let me check with CityGo team if they have already released the source code. It was planned but I am not sure if I has been done.

[jesus-gorronogoitia]

Hi @fchauvel I've contacted CityGo development team. They are planning to release CityGo CityDash source code in few weeks. I will keep you informed once we can get access the code.

[fchauvel]

Closed as similar to #81