Initial commit for progress calculator test refactoring
Change-Id: I19c61d85ae8d1667fe841621af6abad2d3c7015d
This commit is contained in:
parent
cfc8451fc6
commit
110bb7f501
181
specs/2.0/refactor_progress_calculator_integration_test.rst
Normal file
181
specs/2.0/refactor_progress_calculator_integration_test.rst
Normal 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
|
Loading…
Reference in New Issue
Block a user