зеркало из https://github.com/microsoft/lisa.git
doc: fix typos and links.
This commit is contained in:
Chi Song
Chi Song
Родитель
6dc9e451ab
Коммит
c8522178f8
|
|
@ -62,7 +62,7 @@ LISA can be used standalone or called from the current LISA. Learn more
|
|||
from `how to run LISAv2 test cases <https://mslisa.rtfd.io/en/main/run_test/run_legacy.html>`__.
|
||||
|
||||
LISA is in active developing, and a lot of exciting features are being
|
||||
implemented. We’re listening to your
|
||||
implemented. We're listening to your
|
||||
`feedback <https://github.com/microsoft/lisa/issues/new>`__.
|
||||
|
||||
License
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ You are welcome to provide any feedback by `filing an
|
|||
issue <https://github.com/microsoft/lisa/issues/new>`__.
|
||||
|
||||
When there is any question, please check :doc:`FAQ and troubleshooting
|
||||
<troubleshooting>` first. If there is no satisfying answer, don’t hesitate to
|
||||
<troubleshooting>` first. If there is no satisfying answer, don't hesitate to
|
||||
`ask us <https://github.com/microsoft/lisa/issues/new>`__.
|
||||
|
||||
Propose or implement a new feature
|
||||
|
|
@ -58,10 +58,10 @@ Contributing fixes or extensions
|
|||
--------------------------------
|
||||
|
||||
If there is a bug and you want to fix it, feel free to do so by
|
||||
submitting a pull request. We will review it proactively. Once it’s
|
||||
submitting a pull request. We will review it proactively. Once it's
|
||||
approved, we will merge it.
|
||||
|
||||
If you’d like to suggest any extension, please submit a pull request.
|
||||
If you'd like to suggest any extension, please submit a pull request.
|
||||
|
||||
Learn more from :doc:`development guidelines <write_test/guidelines>` and
|
||||
:doc:`how to write extensions <write_test/extension>`.
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ Welcome to Linux Integration Services Automation (LISA)!
|
|||
|CI Workflow| |GitHub license| |Docs|
|
||||
|
||||
**Linux Integration Services Automation (LISA)** is a Linux quality
|
||||
validation system, which consists of two parts：
|
||||
validation system, which consists of two parts:
|
||||
|
||||
- A test framework to drive test execution.
|
||||
- A set of test suites to verify Linux kernel/distribution quality.
|
||||
|
|
@ -22,7 +22,7 @@ on any platforms if the proper orchestrator module implemented.
|
|||
Why LISA
|
||||
--------
|
||||
|
||||
- **Scalable**：Benefit from the appropriate abstractions, **LISA**
|
||||
- **Scalable**: Benefit from the appropriate abstractions, **LISA**
|
||||
can be used to test the quality of numerous Linux distributions
|
||||
without duplication of code implementation.
|
||||
|
||||
|
|
@ -59,7 +59,7 @@ used standalone or called from the current LISA. Learn more from :doc:`how to
|
|||
run LISAv2 test cases <run_test/run_legacy>`.
|
||||
|
||||
LISA is in active developing, and a lot of exciting features are implementing.
|
||||
We’re listening your `feedback
|
||||
We're listening your `feedback
|
||||
<https://github.com/microsoft/lisa/issues/new>`__.
|
||||
|
||||
License
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@ Clone code
|
|||
Development Environment
|
||||
-----------------------
|
||||
|
||||
For making any code changes and running testcases in LISA, you will need to setup a development environment. Instructions for setting up the development environment are present here: :ref:`DevVirtEnv`.
|
||||
For making any code changes and running test cases in LISA, you will need to setup a development environment. Instructions for setting up the development environment are present here: :ref:`DevEnv`.
|
||||
|
||||
Runtime Environment
|
||||
-------------------
|
||||
|
|
@ -129,5 +129,5 @@ computer.
|
|||
FAQ and Troubleshooting
|
||||
-----------------------
|
||||
|
||||
If there’s any problem during the installation, please refer to :doc:`FAQ and
|
||||
If there's any problem during the installation, please refer to :doc:`FAQ and
|
||||
troubleshooting <troubleshooting>`.
|
||||
|
|
|
|||
|
|
@ -71,7 +71,7 @@ Clone code
|
|||
Development Environment
|
||||
-----------------------
|
||||
|
||||
For making any code changes and running testcases in LISA, you will need to setup a development environment. Instructions for setting up the development environment are present here: :ref:`DevVirtEnv`.
|
||||
For making any code changes and running test cases in LISA, you will need to setup a development environment. Instructions for setting up the development environment are present here: :ref:`DevEnv`.
|
||||
|
||||
Runtime Environment
|
||||
-------------------
|
||||
|
|
@ -110,5 +110,5 @@ computer.
|
|||
FAQ and Troubleshooting
|
||||
-----------------------
|
||||
|
||||
If there’s any problem during the installation, please refer to :doc:`FAQ and
|
||||
If there's any problem during the installation, please refer to :doc:`FAQ and
|
||||
troubleshooting <troubleshooting>`.
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@ Introduction
|
|||
============
|
||||
|
||||
**LISA** can be used to run test against the local node, or a remote node; if it
|
||||
is used to run against a remote node, you don’t need to configure anything on
|
||||
is used to run against a remote node, you don't need to configure anything on
|
||||
the remote node.
|
||||
|
||||
.. figure:: img/deploy.svg
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ Some terms
|
|||
Test priority
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
The priority of each test case is determined by the impact if it’s
|
||||
The priority of each test case is determined by the impact if it's
|
||||
failed. The smaller number means the higher priority. For example, if a
|
||||
high-priority test case fails, it means the operating system cannot
|
||||
start. If a lower-priority test case fails, it may mean that a function
|
||||
|
|
@ -42,16 +42,16 @@ failure of high-priority test cases to speed up the analysis.
|
|||
configurations, for example, add firewall rules, install some popular
|
||||
packages. There is data loss with popular configurations. The system
|
||||
cannot be connected via network with default settings. The system
|
||||
performance drops significantly, like SRIOV doesn’t work as expected;
|
||||
performance drops significantly, like SRIOV doesn't work as expected;
|
||||
only one CPU core works on multiple core machine; an important
|
||||
feature doesn’t work with default settings; or the system can be used
|
||||
feature doesn't work with default settings; or the system can be used
|
||||
with limited functionality.
|
||||
- **P2**. The system fails/hangs on start/restart using unpopular
|
||||
configurations. Data loss with unpopular configurations. The system
|
||||
cannot be connected with popular configurations. The system
|
||||
performance drops obviously. An important feature doesn’t work with
|
||||
performance drops obviously. An important feature doesn't work with
|
||||
popular configurations.
|
||||
- **P3**. A feature doesn’t work with unpopular configurations with low
|
||||
- **P3**. A feature doesn't work with unpopular configurations with low
|
||||
impact.
|
||||
- **P4**. The system has obvious but not serious problems on long-haul,
|
||||
stress or performance test scenarios.
|
||||
|
|
@ -116,7 +116,7 @@ more from :doc:`how to run LISA tests <run>` to run different tiers on
|
|||
an image or existing environment.
|
||||
|
||||
LISA comes with a set of test suites to verify Linux distro/kernel
|
||||
quality on Microsoft’s platforms (including Azure, and HyperV). The test
|
||||
quality on Microsoft's platforms (including Azure, and HyperV). The test
|
||||
cases in those test suites are organized with multiple test ``Tiers``
|
||||
(``T0``, ``T1``, ``T2``, ``T3``, ``T4``).
|
||||
|
||||
|
|
|
|||
|
|
@ -214,8 +214,8 @@ If you have prepared a Linux computer for testing, please run LISA with
|
|||
|
||||
lisa -r ./microsoft/runbook/ready.yml -v public_address:<public address> -v "user_name:<user name>" -v "admin_private_key_file:<private key file>"
|
||||
|
||||
The advantage is it’s not related to any infra. The shortage is that,
|
||||
some test cases won’t run in Ready platform, for example, test cases
|
||||
The advantage is it's not related to any infra. The shortage is that,
|
||||
some test cases won't run in Ready platform, for example, test cases
|
||||
cannot get serial log from a VM directly.
|
||||
|
||||
``ready`` runbook also supports tests which require multiple computers (for
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ Linux VM on Azure.
|
|||
authentications, for more information, please refer to :doc: `runbook
|
||||
reference <runbook>`.
|
||||
|
||||
Here, let’s choose ``Azure CLI`` for the setup. You should see a page
|
||||
Here, let's choose ``Azure CLI`` for the setup. You should see a page
|
||||
pop up and all your Azure subscriptions shown in console after
|
||||
running the following command.
|
||||
|
||||
|
|
@ -56,7 +56,7 @@ Linux VM on Azure.
|
|||
}
|
||||
|
||||
Note although the example subscription named “AzureCloud” has the
|
||||
attribute ``isDefault`` as true, it’s not necessary to do so as long
|
||||
attribute ``isDefault`` as true, it's not necessary to do so as long
|
||||
as you provide the correct ``<subscription id>``.
|
||||
|
||||
#. Prepare SSH key pair
|
||||
|
|
@ -66,7 +66,7 @@ Linux VM on Azure.
|
|||
running the test.
|
||||
|
||||
You can skip this step if you already have a key pair. However, if
|
||||
you don’t have a key pair, run below command to create a new one.
|
||||
you don't have a key pair, run below command to create a new one.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
|
|
@ -74,7 +74,7 @@ Linux VM on Azure.
|
|||
|
||||
.. warning::
|
||||
|
||||
Don’t use passphrase to protect your key. LISA doesn’t
|
||||
Don't use passphrase to protect your key. LISA doesn't
|
||||
support that.
|
||||
|
||||
#. Run LISA
|
||||
|
|
|
|||
|
|
@ -13,4 +13,5 @@ Run LISA
|
|||
Run tests on different platforms <platform>
|
||||
Use runbook <runbook>
|
||||
Use command line <command_line>
|
||||
Use transformers <transformers>
|
||||
Analyze test results <understand_results>
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ value of LISA, we decide to continue to invest and have more innovation
|
|||
on LISA. So, we started the next version.
|
||||
|
||||
During the transition time, we keep validating Linux kernels and
|
||||
distributions. We cannot and don’t want to stop to wait for the exciting
|
||||
distributions. We cannot and don't want to stop to wait for the exciting
|
||||
current LISA. The two versions will be co-existing for a while. So, the
|
||||
current LISA version supports to invoke previous LISAv2.
|
||||
|
||||
|
|
@ -36,13 +36,13 @@ Follow `LISAv2
|
|||
document <https://github.com/microsoft/lisa/blob/master/README.md>`__
|
||||
to understand prerequisites and prepare secret files.
|
||||
|
||||
Note, you don’t need to clone the LISAv2 yourself, the current LISA will
|
||||
Note, you don't need to clone the LISAv2 yourself, the current LISA will
|
||||
clone it when running.
|
||||
|
||||
Limitations
|
||||
-----------
|
||||
|
||||
1. The Test in Parallel of LISAv2 doesn’t support with the current LISA
|
||||
1. The Test in Parallel of LISAv2 doesn't support with the current LISA
|
||||
together. The current LISA implements test matrix to replace current
|
||||
test in parallel in LISAv2. There is no plan for compatibility with
|
||||
LISAv2 on this.
|
||||
|
|
@ -54,7 +54,7 @@ Limitations
|
|||
Road map
|
||||
--------
|
||||
|
||||
We’re migrating LISAv2 test cases to current LISA by test case priority.
|
||||
We're migrating LISAv2 test cases to current LISA by test case priority.
|
||||
We will keep t0 to tx runbooks update to date. When test cases migrated,
|
||||
they will be included in current LISA, and remove from LISAv2. It’s
|
||||
they will be included in current LISA, and remove from LISAv2. It's
|
||||
transparent when running LISA tests.
|
||||
|
|
|
|||
|
|
@ -433,7 +433,7 @@ type: bool, optional, default is False.
|
|||
When set to True, the value of this variable will be masked in log and
|
||||
other output information.
|
||||
|
||||
Recommend to use secret file or env variable. It’s not recommended to
|
||||
Recommend to use secret file or env variable. It's not recommended to
|
||||
specify secret value in runbook directly.
|
||||
|
||||
file
|
||||
|
|
@ -471,7 +471,7 @@ type: str, required, the type of transformer. See `transformers
|
|||
<https://github.com/microsoft/lisa/tree/main/lisa/transformers>`__ for all
|
||||
transformers.
|
||||
|
||||
See :ref:`documentation for transformers <transformers.rst>`
|
||||
See :doc:`documentation for transformers<transformers>`.
|
||||
|
||||
.. _name-3:
|
||||
|
||||
|
|
@ -480,8 +480,8 @@ name
|
|||
|
||||
type: str, optional, default is the ``type``.
|
||||
|
||||
Unique name of the transformer. It’s depended by other transformers. If
|
||||
it’s not specified, it will use the ``type`` field. But if there are two
|
||||
Unique name of the transformer. It's depended by other transformers. If
|
||||
it's not specified, it will use the ``type`` field. But if there are two
|
||||
transformers with the same type, one of them should have name at least.
|
||||
|
||||
prefix
|
||||
|
|
@ -489,7 +489,7 @@ prefix
|
|||
|
||||
type: str, optional, default is the ``name``.
|
||||
|
||||
The prefix of generated variables from this transformer. If it’s not
|
||||
The prefix of generated variables from this transformer. If it's not
|
||||
specified, it will use the ``name`` field.
|
||||
|
||||
depends_on
|
||||
|
|
|
|||
|
|
@ -162,7 +162,7 @@ type: string | Default: "None" | Allowed Values: "None", "ReadOnly", "ReadWrite"
|
|||
rename
|
||||
^^^^^^
|
||||
type: <key>: <value>
|
||||
Used to rename the ouput variable
|
||||
Used to rename the output variable
|
||||
|
||||
eg: azure_sig_url: shared_gallery
|
||||
Rename's the transformer output `azure_sig_url` to `shared_gallery`
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Understand test results
|
|||
Overview
|
||||
--------
|
||||
|
||||
It’s essential to understand the results after running tests. LISA has 7
|
||||
It's essential to understand the results after running tests. LISA has 7
|
||||
kinds of test results in total: 3 of which are intermediate results, and
|
||||
4 of which are final results, as explained in sections below. Each test
|
||||
case can and will be moved from one result to another but can never have
|
||||
|
|
|
|||
|
|
@ -48,4 +48,4 @@ Other issues
|
|||
|
||||
Please check `known issues <https://github.com/microsoft/lisa/issues>`__
|
||||
or `file a new issue <https://github.com/microsoft/lisa/issues/new>`__
|
||||
if it doesn’t exist.
|
||||
if it doesn't exist.
|
||||
|
|
|
|||
|
|
@ -166,7 +166,7 @@ cases, other requirements of the test cases in addition to the default
|
|||
ones should be defined explicitly.
|
||||
|
||||
The platform provides environments with different **capability**. The
|
||||
capabilities of environments are loaded from the platform’s API. Only if
|
||||
capabilities of environments are loaded from the platform's API. Only if
|
||||
the capability of an environment meets the requirements of a test case,
|
||||
the test case can be run on this environment.
|
||||
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ Follow the :ref:`quick_start:installation` steps to
|
|||
prepare the source code. Then follow the steps below to set up the corresponding
|
||||
development environment.
|
||||
|
||||
.. _DevVirtEnv:
|
||||
.. _DevEnv:
|
||||
|
||||
Creating a LISA development virtual environment
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -90,7 +90,7 @@ If you wish to deactivate the virtual environment, use the ``deactivate`` comman
|
|||
Visual Studio Code
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
1. Click on the Python version at the bottom left of the editor’s window
|
||||
1. Click on the Python version at the bottom left of the editor's window
|
||||
and select the Python interpreter which Poetry just created. If you do not
|
||||
find it, check :doc:`FAQ and troubleshooting <../troubleshooting>` for extra
|
||||
instructions. This step is important because it ensures that the current
|
||||
|
|
@ -382,8 +382,8 @@ Extended reading
|
|||
----------------
|
||||
|
||||
- `Python Design Patterns <https://python-patterns.guide/>`__. A
|
||||
fantastic collection of material for using Python’s design patterns.
|
||||
- `The Hitchhiker’s Guide to
|
||||
fantastic collection of material for using Python's design patterns.
|
||||
- `The Hitchhiker's Guide to
|
||||
Python <https://docs.python-guide.org/>`__. This handcrafted guide
|
||||
exists to provide both novice and expert Python developers a best
|
||||
practice handbook for the installation, configuration, and usage of
|
||||
|
|
|
|||
|
|
@ -142,7 +142,7 @@ Feature
|
|||
-------
|
||||
|
||||
The base class is :class:`Feature` in ``feature``. All examples are in `features
|
||||
<https://github.com/microsoft/lisa/tree/main/lisa/features>`__ and Azure’s
|
||||
<https://github.com/microsoft/lisa/tree/main/lisa/features>`__ and Azure's
|
||||
`features.py
|
||||
<https://github.com/microsoft/lisa/blob/main/lisa/sut_orchestrator/azure/features.py>`__.
|
||||
|
||||
|
|
@ -155,7 +155,7 @@ Support an existing feature in a platform
|
|||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
1. Implement the feature, so that it can work normally. Learn more from
|
||||
the ``SerialConsole`` implementation in Azure’s `features.py
|
||||
the ``SerialConsole`` implementation in Azure's `features.py
|
||||
<https://github.com/microsoft/lisa/blob/main/lisa/sut_orchestrator/azure/features.py>`__.
|
||||
|
||||
2. The platform should declare which features it supports, and where the
|
||||
|
|
@ -177,7 +177,7 @@ Support an existing feature in a platform
|
|||
[features.StartStop.name(), features.SerialConsole.name()]
|
||||
)
|
||||
|
||||
4. Learn more from Azure’s
|
||||
4. Learn more from Azure's
|
||||
`platform_.py
|
||||
<https://github.com/microsoft/lisa/blob/main/lisa/sut_orchestrator/azure/platform_.py>`__.
|
||||
|
||||
|
|
@ -261,15 +261,15 @@ The base class is :class:`Platform` in ``platform_``.
|
|||
If a platform needs to specify settings in runbook, it can be
|
||||
implemented in two places.
|
||||
|
||||
1. Platform schema. Learn more from ``AzurePlatformSchema`` in Azure’s
|
||||
1. Platform schema. Learn more from ``AzurePlatformSchema`` in Azure's
|
||||
`platform_.py
|
||||
<https://github.com/microsoft/lisa/blob/main/lisa/sut_orchestrator/azure/platform_.py>`__.
|
||||
|
||||
2. Node schema. Learn more from ``AzureNodeSchema`` in Azure’s
|
||||
2. Node schema. Learn more from ``AzureNodeSchema`` in Azure's
|
||||
`common.py
|
||||
<https://github.com/microsoft/lisa/blob/main/lisa/sut_orchestrator/azure/common.py>`__.
|
||||
|
||||
3. Use them in the platform code. Learn more from Azure’s
|
||||
3. Use them in the platform code. Learn more from Azure's
|
||||
`platform_.py
|
||||
<https://github.com/microsoft/lisa/blob/main/lisa/sut_orchestrator/azure/platform_.py>`__.
|
||||
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ brief overview of the most important parts:
|
|||
- To avoid conflicts with the standard library, you can add an
|
||||
underscore, such as ``id_``.
|
||||
- Leading lines such as ``_data`` apply to non-public methods and
|
||||
instance variables. Subclasses can use it. If you don’t use it in a
|
||||
instance variables. Subclasses can use it. If you don't use it in a
|
||||
subclass, use it like ``__data`` in a superclass.
|
||||
- If there is a pair of ``get_x`` and ``set_x`` methods without
|
||||
additional parameters, please use the built-in ``@property``
|
||||
|
|
@ -59,7 +59,7 @@ elsewhere, such as tools, functions, or private methods in test suites.
|
|||
An example: Be careful when using ``sleep``! The only way to use sleep
|
||||
is in polling mode. This means that you must wait for something with
|
||||
regular inspections. In the inspection cycle, you can wait for a
|
||||
reasonable period. Don’t wait for 10 seconds of sleep. This causes two
|
||||
reasonable period. Don't wait for 10 seconds of sleep. This causes two
|
||||
problems, 1) if it is too short, the case may fail; 2) if it is long
|
||||
enough, it will slow down the running speed.
|
||||
|
||||
|
|
@ -107,7 +107,7 @@ contradictory, but they can be achieved through different INFO and DEBUG
|
|||
levels. LISA always enables the DEBUG level in the log file, while the
|
||||
INFO level is the default setting on the console.
|
||||
|
||||
In LISA, when writing log lines in the code, it’s recommended to
|
||||
In LISA, when writing log lines in the code, it's recommended to
|
||||
consider what the test runner needs to know, instead of what the
|
||||
developer needs to know, which should be done in code comments.
|
||||
|
||||
|
|
@ -117,7 +117,7 @@ developer needs to know, which should be done in code comments.
|
|||
|
||||
When writing code, please keep using and improving the log. If you
|
||||
need to debug step by step, it means you need to improve the log. If
|
||||
you don’t understand the meaning of the log, others may not as well,
|
||||
you don't understand the meaning of the log, others may not as well,
|
||||
so please optimize the log at DEBUG level. In addition, if you find
|
||||
duplicate information, please merge it.
|
||||
|
||||
|
|
@ -186,7 +186,7 @@ Therefore, this message should be as helpful as possible.
|
|||
The error message should include what happened and how to resolve it. It
|
||||
may not be easy to provide all the information for the first time, but
|
||||
guesswork is also helpful. At the same time, the original error message
|
||||
is also useful, please don’t hide it.
|
||||
is also useful, please don't hide it.
|
||||
|
||||
For examples,
|
||||
|
||||
|
|
@ -226,7 +226,7 @@ When writing the assertion,
|
|||
yourself. ``assert_that(vmbuses).is_length(6)`` is better than
|
||||
``assert_that(len(vmbuses)).is_equal_to(6)``. It is simpler and the
|
||||
error message is clearer.
|
||||
- Don’t forget to use powerful collection assertions. They can compare
|
||||
- Don't forget to use powerful collection assertions. They can compare
|
||||
ordered list by ``contains`` (actual value is superset),
|
||||
``is_subset_of`` (actual value is subset), and others.
|
||||
|
||||
|
|
@ -258,7 +258,7 @@ its lower cost of analysis.
|
|||
reproduced.
|
||||
|
||||
In LISA, test cases fail due to exceptions, and exception messages are
|
||||
treated as single-line messages. When writing test cases, it’s time to
|
||||
treated as single-line messages. When writing test cases, it's time to
|
||||
adjust the exception message. Therefore, after completing the test case,
|
||||
many errors will be explained well.
|
||||
|
||||
|
|
@ -297,7 +297,7 @@ following steps:
|
|||
translate <https://translate.google.com/>`__ to convert it to
|
||||
English.
|
||||
4. Convert the English version back to your language and check. If it
|
||||
doesn’t make sense after translating back, it means the sentence is
|
||||
doesn't make sense after translating back, it means the sentence is
|
||||
too complicated. Make it simpler, and then start from step 1 again.
|
||||
5. Once satisfied, you can use `Microsoft
|
||||
Editor <https://www.microsoft.com/en-us/microsoft-365/microsoft-editor>`__
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ following documents to ensure a better LISA development experience. We believe
|
|||
that the engineering excellence is equally important in addition to new test
|
||||
cases, since any test case will be run thousands of times, and many people will
|
||||
read and troubleshoot it. Therefore, a good test case following the guidelines
|
||||
can save everyone’s time.
|
||||
can save everyone's time.
|
||||
|
||||
- :doc:`Basic concepts <concepts>` introduces design considerations
|
||||
and how components work together in LISA. We recommend every LISA developer
|
||||
|
|
@ -153,7 +153,7 @@ Definition in test case
|
|||
case of more importance, and thus it will be run more often. The
|
||||
lowest value (most prioritized) is ``0``.
|
||||
- **requirement** defines the requirements in this case. If no
|
||||
requirement specified, the test suite’s or the default global
|
||||
requirement specified, the test suite's or the default global
|
||||
requirements will apply.
|
||||
- **timeout** defines when the test case will be ended by timeout. The default
|
||||
value is 3600 seconds. It applies to test method and before/after test case
|
||||
|
|
@ -314,7 +314,7 @@ other functionality.
|
|||
get_environment_information
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
It returns the information of an environment. It’s called when a test
|
||||
It returns the information of an environment. It's called when a test
|
||||
case is completed.
|
||||
|
||||
Please note that to avoid the mutual influence of hooks, there is no
|
||||
|
|
|
|||
|
|
@ -87,16 +87,16 @@ def parse_args() -> Namespace:
|
|||
support_working_path(parser)
|
||||
support_id(parser)
|
||||
|
||||
# Default to ‘run’ when no subcommand is given.
|
||||
# Default to 'run' when no subcommand is given.
|
||||
parser.set_defaults(func=commands.run)
|
||||
|
||||
subparsers = parser.add_subparsers(dest="cmd", required=False)
|
||||
|
||||
# Entry point for ‘run’.
|
||||
# Entry point for 'run'.
|
||||
run_parser = subparsers.add_parser("run")
|
||||
run_parser.set_defaults(func=commands.run)
|
||||
|
||||
# Entry point for ‘list-start’.
|
||||
# Entry point for 'list-start'.
|
||||
list_parser = subparsers.add_parser(constants.LIST)
|
||||
list_parser.set_defaults(func=commands.list_start)
|
||||
list_parser.add_argument(
|
||||
|
|
@ -114,7 +114,7 @@ def parse_args() -> Namespace:
|
|||
help="ignore test case selection, and display all test cases",
|
||||
)
|
||||
|
||||
# Entry point for ‘check’.
|
||||
# Entry point for 'check'.
|
||||
check_parser = subparsers.add_parser("check")
|
||||
check_parser.set_defaults(func=commands.check)
|
||||
|
||||
|
|
|
|||
|
|
@ -130,7 +130,7 @@ class TimeSync(TestSuite):
|
|||
1. Check clock source name is one of hyperv_clocksource_tsc_page,
|
||||
lis_hv_clocksource_tsc_page, hyperv_clocksource, tsc,
|
||||
arch_sys_counter(arm64).
|
||||
(there’s a new feature in the AH2021 host that allows Linux guests so use
|
||||
(there's a new feature in the AH2021 host that allows Linux guests so use
|
||||
the plain "tsc" instead of the "hyperv_clocksource_tsc_page",
|
||||
which produces a modest performance benefit when reading the clock.)
|
||||
2. Check CPU flag contains constant_tsc from /proc/cpuinfo.
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче