create a more fine grained interface to camp

[vassik]

we can specify location of feature.yml we can specify location of composite.yml we can specify location of images.yml we can specify location of output directory with generated configurations

[jesus-gorronogoitia]

I would add other features to improve the CAMP interface:

• we can specify the location of the input docker-compose.yml
• we can specify the maximum number of configurations to be generated (upper bound). CAMP does not necessarily be able to generate up to those configurations, but if it can, no more than this number of configurations will be generated.

[jesus-gorronogoitia]

In relation to this requirement for fine tune STAMP configuration, the ability to specify locations for CAMP input models, such as feature.yml and composite.yml should enable us to define different configuration amplification domains for CAMP. For instance, in scenario 1) Atos CityGo could be interesting on testing it under different functional configurations, where default backend dependencies are replaced by others (OS distros/versions, RDBMS engines/versions, python 2.X/3.X, Apache vs Nginx), or in scenario 2) Atos CityGo is tested under different parameterizations of the Apache or Nginx engines or the PostgreSQL engine for maximizing its performance and/or resources consumption. Therefore, specifying these CAMP input models is quire relevant.

[jesus-gorronogoitia]

Once this fine-grained CAMP user interface is implemented, the CAMP documentation (user-guide) should be updated accordingly