Initial commit for progress calculator test refactoring

Change-Id: I19c61d85ae8d1667fe841621af6abad2d3c7015d
This commit is contained in:
Lei Lei 2014-11-26 17:57:01 -08:00
parent cfc8451fc6
commit 110bb7f501

View File

@ -0,0 +1,181 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
=================================================
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:
.. code-block:: python
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:
.. code-block:: python
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/checkpoint_*number*/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