docs fixes

docs/entities/datasources.md

@@ -26,9 +26,9 @@ For instance, if you had Github repository `https://github.com/amyasnikov/device
 
 #### Device Config Path
 
-This is the template of the path to device config file inside the repository. You can use [Jinja2](https://jinja.palletsprojects.com/en/3.0.x/templates/) expressions for this template. The only available context variable is `device`.
+This is the template of the path to device config file inside the Data Source. You can use [Jinja2](https://jinja.palletsprojects.com/en/3.0.x/templates/) expressions for this template. The only available context variable is `device`.
 
-Let's suppose that you have a repository with device configurations
+Let's suppose that you have a Data Source with device configurations
 
 ```console
 device_repo

docs/entities/namesets.md

@@ -1,6 +1,6 @@
 # Name Sets
 
-Name Sets is the method of creating some arbitrary Python functions or classes to later use them in Compliance Tests. Name Sets also could be used to inject some Python standard library functions into test expressions.
+Name Sets is the method of creating some arbitrary Python functions or classes to later use them in Compliance Tests. Name Sets also can be used to inject some Python standard library functions into test expressions.
 
 One of the common approaches is to move complex expression from tests into a nameset function with appropriate name.
 Consider this serialized config:

docs/entities/results_and_reports.md

@@ -60,7 +60,7 @@ For this expression you can get the following explanation:
 
 Report ties together Test Results generated from one execution of the [Run Compliance Tests](scripts.md#run-compliance-tests) script.
 
-The user may choose either to create a report together with the Test Results during the Run Compliance Tests script execution or no.
+A user may choose either to create a report together with the Test Results during the Run Compliance Tests script execution or no.
 
 At the report page you can observe test result statistics (total and grouped by severity). Moreover, in web GUI you can choose an additional param to group the results by and display the statistics for each group.
 

docs/entities/scripts.md

@@ -16,10 +16,10 @@ The script may generate a lot of DB queries. To spread the queries over time you
 
 | **Param**                   | **API Param** | **Description**                                                   |
 |-----------------------------|---------------|-------------------------------------------------------------------|
-| Sync Data Sources           | sync_datasources  | Sync all Data Sources which are bound to Devices participating in the script execution|
-| Make Compliance Report      | make_report   | Create Report together with Test Results                          | 
+| Sync Data Sources           | sync_datasources  | Sync all Data Sources which are bound to Devices<br/> participating in the script execution|
+| Make Compliance<br/>Report  | make_report   | Create Report together with Test Results                          | 
 | Specific Selectors          | selectors     | Run the tests only for a limited number of selectors              |
 | Specific Devices            | devices       | Run the tests only for a limited number of devices.               |
-| Specific Test Tags          | test_tags     | Run only those tests which have at least one of the specified tags|
-| Explanation Verbosity Level | explanation_verbosity | **0** - No explanation at all.<br/>**1** - Explanation of the calculation steps<br/>**2** - the same as **1** plus deepdiff value in case of comparisons|
-| Override DataSource         | override_datasource| Override Data Sources bound to Devices and use this one instead. It may be useful if you want to use **Validity Polling** Data Source just to run some operational tests only for now.|
+| Specific Test Tags          | test_tags     | Run only those tests which have at least one of<br/> the specified tags|
+| Explanation Verbosity<br/>Level | explanation_verbosity | **0** - No explanation at all.<br/>**1** - Explanation of the calculation steps<br/>**2** - the same as **1** plus deepdiff value in case of<br/> comparisons|
+| Override DataSource         | override_datasource| Ignore Data Sources bound to Devices and use<br/> this one instead. It may be useful if you want to<br/> use **Validity Polling** Data Source just to run some<br/> operational tests only for now.|

docs/entities/serializers.md

@@ -4,24 +4,24 @@ Serializer is used to translate/parse device configuration (or other state info)
 
 The main approach used in Validity is [Template Text Parser (TTP)](https://ttp.readthedocs.io/en/latest/Overview.html). This library allows you to define text template and then parse the data according to that template. Template language is very simple and looks like Jinja2 in the reverse way.
 
-There is another one way: you can somehow get JSON config from plain config by yourself, store it in Git Repository and say Validity to read the file as already prepared JSON or YAML. This can be useful for some network vendors which have their own tools for getting JSON-formatted config (e.g. `| display json` on Junos).
+There is another one way: you can somehow get already serialized data and tell Validity read it as already prepared JSON or YAML. This can be useful for some network vendors which have their own tools for getting JSON-formatted config (e.g. `| display json` on Junos).
 
 ## Fields
 
 #### Name
 
-The name of the serializer. Must be unique.
+The name of the Serializer. Must be unique.
 
 #### Config Extraction Method
 
-The field with the following choices: **TTP** and **YAML**
+The field with the following choices: **TTP**, **YAML**, **ROUTEROS**
 
 !!! note
     Remember that YAML is the superset of JSON. So, YAML serializer can be used to read any JSON file.
 
 This field defines the way of getting serialized config from the text.
 
-**TTP** choice requires defining a template (see the other fields below).
+**TTP** choice requires defining a template (see other fields below).
 
 **YAML** serializer has no additional properties and may be used to read already prepared JSON or YAML file.
 
@@ -31,7 +31,7 @@ This field defines the way of getting serialized config from the text.
 
 #### TTP Template
 
-Inside this field at the serializer page you can view your template defined either via DB or via Git.
+Inside this field at the Serializer page you can view your template defined either via DB or via Data Source.
 
 At the add/edit form this field is used to store TTP Template inside the DB.
 This option fits well when you have small templates or just need to quickly test some setup.
@@ -52,10 +52,10 @@ This is the best option if you have plenty of complex Serializers and want to ge
 Binding Serializer to Device is required to be able to serialize device configuration found by **device_config_path**.
 
 !!! note
-    You don't need to bind Serializer to Devices if you use direct polling. In this case Serializers bound to [Commands](commands.md) are used.
+    You don't need to bind Serializer to Devices if you use direct polling. In this case Serializers are bound to [Commands](commands.md).
 
 
-There are 3 ways to bind a serializer to device:
+There are 3 ways to bind a Serializer to Device:
 
 * Set the serializer at **Manufacturer** level. Go to Manufacturer page at set the serializer via custom fields. This action applies this serializer to all the devices with this Manufacturer.
 
@@ -64,7 +64,8 @@ There are 3 ways to bind a serializer to device:
 * Set the serializer at the individual **Device** level. Go to Device page at set the serializer via custom fields. This action applies this serializer to one specific device and overwrites the values from Device Type and Manufacturer.
 
 
-When device has bound Serializer and Data Source you can find out how serialized config looks like at the Device page (**Serialized State** tab) or by using API handle `/api/plugins/validity/devices/<id>/serialized_state/?name=config`
+When device has bound Serializer and Data Source you can find out how serialized config looks like at the Device page (**Serialized State** tab) or by using API handle<br/>
+`/api/plugins/validity/devices/<id>/serialized_state/?name=config`
 
 
 ## MikroTik parsing
@@ -75,7 +76,7 @@ Validity has an option to parse MikroTik RouterOS config files without TTP. You
 * At the same time, MikroTik configuration has the same structure as JSON may have. So, it's very easy to translate it using simple Python tools.
 
 !!! warning
-    Parser works only if the configuration structure strictly follows the one in `/export` command (or in .rsc file).
+    Parser works only if the configuration structure strictly follows the `/export` command format.
 
     Things like `/ip address add address=1.2.3.4/24` won't be parsed
 

docs/entities/tests.md

@@ -142,13 +142,13 @@ One of the `LOW`, `MIDDLE` or `HIGH`. This param influences the future analysis
 The list of selectors this test is bound to.
 
 #### Description
-Description of the test is mandatory. Writing the meaningful description for each of your tests may facilitate the future usage/modification of this test and is considered a best practice.
+Description of the test is mandatory. Writing meaningful description for each of your tests may facilitate the future usage/modification of this test and is considered a best practice.
 
 #### Expression
-Inside this field at the test page you can view your expression defined either via DB or via Git.
+Inside this field at the test page you can view your expression defined either via DB or via Data Source.
 
 At the add/edit form this field is used to store an expression code inside the DB.
-This option fits well when you want to quickly check your test or just don't want to make things complex with Git.
+This option fits well when you want to quickly check your test or just don't want to make things complex with Git-based storage.
 
 #### Data Source and Data File
 

docs/features/dynamic_pairs.md

@@ -8,7 +8,7 @@ The concept of 2 similar network devices working together and providing redundan
 ## How to define a dynamic pair
 
 Dynamic pairs are defined under **Selector** instance (**Dynamic Pairs** field).
-The main idea is to define some kind of rule which can definitely match one device with another within one Selector.
+The main idea is to define some kind of a rule which can definitely match one device with another within one Selector.
 
 #### By Name
 

docs/features/state.md

@@ -3,11 +3,11 @@
 **State** is a special dict-like object which contains serialized configuration or/and serialized command outputs for a particular Device instance. State contents can be accessed inside [Compliance Test](../entities/tests.md) code via `device.state.<command_label>` expression. If command has `retrieves_config=True` option, its serialized contents are available through `device.state.config`.
 
 !!! note
-    `device.config` is backward compatible shortcut for `device.state.config`
+    `device.config` is the backward compatible shortcut for `device.state.config`
 
 `device.state.config` may be filled via 2 different options:
-* if Device has bound [Poller](../entities/pollers.md) and this Poller has bound [Command](../entities/commands.md) which has `retrieves_config=True`, then serialized output of this Command will be inserted into `device.state.config`
 
+* if Device has bound [Poller](../entities/pollers.md) and this Poller has bound [Command](../entities/commands.md) which has `retrieves_config=True`, then serialized output of this Command will be inserted into `device.state.config`
 * if Device has bound [Serializer](../entities/serializers.md) and [Data Source](../entities/datasources.md) which has `device_config_path` set, then serialized contents of the file defined by `device_config_path` will be written inside `device.state.config`.
 
 When both options are applicable, the last one takes precedence over the first one.

docs/plugin_settings.md

@@ -1,7 +1,7 @@
 # Plugin Settings
 
 
-Validity has some settings which could be changed through [PLUGINS_CONFIG](https://docs.netbox.dev/en/stable/plugins/#configure-plugin) variable inside your `configuration.py`.
+Validity has some settings which can be changed through [PLUGINS_CONFIG](https://docs.netbox.dev/en/stable/plugins/#configure-plugin) variable inside your `configuration.py`.
 
 ## Settings
 

docs/quickstart.md

@@ -13,7 +13,7 @@ You can figure out how to work with Validity using NetBox Web UI in this video:
 
 
 ## Polling
-    Current guide is based on a Git repository as a source of device configuration data. If you want get device configuration or other data directly from network devices, consider [Quick Start With Polling](quickstart_polling.md) article.
+Current guide is based on a Git repository as a source of device configuration data. If you want to get device configuration or other data directly from network devices, consider [Quick Start With Polling](quickstart_polling.md) article.
 
 
 ## Preparing Git repository
@@ -88,7 +88,7 @@ device2 = nb.dcim.devices.create(
 ```
 
 ### Data Source and Serializer instances
-* Create **device_repo** Data Source entity, mark it as default
+* Create Data Source entity, mark it as default
 
 !!! warning
     Unfortunately, according to this [NetBox bug](https://github.com/netbox-community/netbox/issues/14879), configuration of custom fields for a Data Source is not available through REST API prior to NetBox v3.7.2
@@ -108,7 +108,7 @@ data_source = nb.core.data_sources.create(
 )
 ```
 
-* Create Serializer to translate device configuration into JSON and then bind this serializer to created devices (e.g. via device type).
+* Create Serializer to translate device configuration into JSON and then bind this Serializer to created devices (e.g. via device type).
 
 ```python
 template = '''
@@ -177,7 +177,7 @@ print(json.dumps(serialized_state['results'][0]['value'], indent=4))
 
 ### Compliance Test
 
-* Create a selector. Selector is used to gather some subset of devices to later apply compliance tests only to that subset. For now, we just need a selector that gathers all the devices
+* Create a Selector. Selector is used to gather some subset of devices to later apply Compliance Tests only to that subset. For now, we just need a selector that gathers all the devices
 
 ```python
 selector = nb.plugins.validity.selectors.create(name='all', name_filter='.*')
@@ -209,8 +209,8 @@ So, if these 2 lists are equal, then each interface on the device has a descript
 
 ## Running the script and evaluating the results
 
-Now all the required entities are created, and you can execute the test you created.
-This could be done via **RunTests** script.
+Now all the required entities are created, and you can execute the test you've created.
+This can be done via **RunTests** script.
 
 ```python
 resp = requests.post(

docs/quickstart_polling.md

@@ -62,7 +62,7 @@ ip2 = nb.ipam.ip_addresses.create(
     assigned_object_id=junos2_fxp.id
 )
 ```
-When IPs are bound to interfaces and interfaces are bound to devices, primary IPs can be assigned
+When IPs are bound to interfaces and interfaces are bound to devices, primary IPs can be assigned to devices
 
 ```python
 junos1.primary_ip4 = ip1.id
@@ -75,6 +75,7 @@ Now both devices have Primary IP and are ready to be polled.
 
 #### Commands and Poller
 Let's set up 2 [Commands](entities/commands.md):
+
 * **show configuration**
 * **show chassis routing-engine**
 
@@ -95,7 +96,7 @@ show_re = nb.plugins.validity.commands.create(
     label='show_re',
     serializer=json_serializer.id,
     type='CLI',
-    parameters={'cli_command': 'show configuration | display json | no-more'}
+    parameters={'cli_command': 'show chassis routing-engine | display json | no-more'}
 )
 ```
 
@@ -114,19 +115,19 @@ junos_poller = nb.plugins.validity.pollers.create(
 Finally, Poller has to be bound to appropriate Devices. Let's do it at Manufacturer level.
 
 ```python
-juniper.custom_fields = {'poller': junos_poller}
+juniper.custom_fields = {'poller': junos_poller.id}
 juniper.save()
 ```
 
 ## Performing Polling
 
 For polling purposes Validity creates one special Data Source: **Validity Polling**. "Sync" of this Data Source causes polling of all bound Devices.
 
-Bind Devices to Data Source can be done in 2 ways: either by marking the Data Source as default or by assigning the Data Source to a Tenant which contains required Devices.
+Binding of devices to Data Source can be done in 2 ways: either by marking the Data Source as default or by assigning the Data Source to a Tenant which contains required devices.
 
-Let's create a Tenant with bound Data Source and bind our Junos Devices to this Tenant.
+Let's create a Tenant with bound Data Source and bind our Junos devices to this Tenant.
 ```python
-validity_polling = nb.plugins.validity.get(name='Validity Polling')
+validity_polling = nb.core.data_sources.get(name='Validity Polling')
 
 tenant1 = nb.tenancy.tenants.create(
     name='tenant1',
@@ -135,7 +136,7 @@ tenant1 = nb.tenancy.tenants.create(
 )
 
 junos1.tenant = tenant1.id
-junos2.tenant = tenant2.id
+junos2.tenant = tenant1.id
 
 junos1.save()
 junos2.save()