compass-specs/specs/2.0/refactor_progress_calculator_integration_test.rst
Lei Lei 110bb7f501 Initial commit for progress calculator test refactoring
Change-Id: I19c61d85ae8d1667fe841621af6abad2d3c7015d
2014-11-26 17:59:47 -08:00

4.0 KiB

Refactor Integration Test for Progress Calculator

Include the URL of your launchpad blueprint:

https://blueprints.launchpad.net/compass/+spec/new-integration-test-for-progress-calculator

To decrease the amount of code base of progress calculator integration test and improve code performance, by creating a log-file generator.

Problem description

In the previous integration test, log templates have been used which contains a large amount of unnecessary lines of code. Basiclly, the log file templates are stored in data/ under same directory as test code. Everytime integration test is ran, the log file templates will be copied to /tmp/ for the further process.

The issue with this are: Increasing the workload due to the redundant lines in log templates. Reducing code performance.

Proposed change

This blueprint proposes to create a log-file generator to only gather lines with critical keys.

Dividing the install progress in to five parts. Each part represents 20% of the progress which is also a checkpoint. To generate desired log files, a dictionary will be used to store log information.

Use log name as the key and content as the value.

Example:

file_line_mapping = {
    "file_1": ["line_1", "line_2", "line_3"],
    "file_2": ["line_4", "line_5", "line_6"]
}

Here file_line_mapping is a dictionary that provides the key lines of each file. There will be another dictionary that will provide the position of each check_point.

Example:

check_points = {
    "check_point_1": {
        "percentage": 0.2,
        "position": {
            "file": "file_1",
            "line": "line_2"
        },
    },
    "check_point_2": {
        "percentage": 0.4,
        "position": {
            "file": "file_2",
            "line": "line_4"
        }
     }
 }

For example, if we are going to test "check_point_2", the coresponding log file should be generated for check_point_2. Using the example above, the generator will first locate the position of "check_point_2", then go to "file_line_mappping". It will create a file for each key value pair prior to check_point_2's position, where each file will be filled with all the lines in its list. The generator will stop creating files and writing lines when it reaches the check_point's position.

In this case, it is clear that when the progress reaches each checkpoint, what the current state and percentage of the installation are.

Instead of using log file template which has thoudsans of lines, log files generated by this strategy with only "progress calculator understandable" content would signaficantly reduce the code base.

Alternatives

None

Data model impact

None

REST API impact

None

Security impact

None

Notifications impact

None

Other end user impact

None

Performance Impact

None

Other deployer impact

None

Developer impact

None

Implementation

Assignee(s)

Lei Lei

Work Items

  • Create a dictionary with necessary information for the log file.
  • Create a dictionary for check_point and log position mapping.
  • Write generater logic to enerate proper logs corresponding to checkpoint mapping dictionary.
  • Such generator will create a directory like this: /tmp/mocklogs/uuid.uuid4()/anamon/checkpointnumber/server1.1/ put the log files in the path.

Dependencies

None

Testing

Major impact on testing to accompany this proposal. Testing of progress calculator will be changed.

Documentation Impact

None

References

None