Formatting bullet indentation fixes

Author: ShawnMcKee

docs/network-troubleshooting/osg-debugging-document.md

@@ -2,8 +2,10 @@
 
 _Edited By: J. Zurawski – Internet2, S. McKee – University of Michigan_
 
-_February 4_
-_# th_ _2013_
+_February 4th 2013_
+
+!!! note
+    This document is old but still may have useful information.  Many tools it references may no longer be supported or available.
 
 # Abstract
 

docs/perfsonar/deployment-models.md

@@ -3,26 +3,26 @@
 The primary motivation for perfSONAR deployment is to test isolation, i.e. only one end-to-end test should run on a host at a time. This ensures that the test results are not impacted by the other tests. Otherwise it is much more difficult to interpret test results, which may vary due to host effects rather then network effects. Taking this into account it means that perfSONAR measurement tools are much more accurate running on a dedicated hardware and while it may be useful to run them on other hosts such as Data Transfer Nodes the current recommendation is to have specific measurement machine. In addition, as bandwidth testing could impact latency testing, we recommend to deploy two different nodes, each focused on specific set of tests. The following deployment options are currently available:
 
 * **Bare metal** - preffered option in one of two possible configurations:
-  * Two bare metal servers, one for latency node, one for bandwidth node
-  * One bare metal server running both latency and bandwidth node together provided that there are two NICs available, please refer to [dual NIC](#multiple-nic-network-interface-card-guidance) section for more details on this.
+    * Two bare metal servers, one for latency node, one for bandwidth node
+    * One bare metal server running both latency and bandwidth node together provided that there are two NICs available, please refer to [dual NIC](#multiple-nic-network-interface-card-guidance) section for more details on this.
 * **Virtual Machine** - if bare metal is not available then it is also possible to run perfSONAR on a VM, however there are a set of additional requirements to fulfill:
-  * Full-node VM is strongly preferred, having 2 VMs (latency/bandwidth node) on a single bare metal. Mixing perfSONAR VM(s) with others might have an impact on the measurements and is therefore not recommended.
-  * VM needs to be configured to have SR-IOV to NIC(s) as well as pinned CPUs to ensure bandwidth tests are not impacted (by hypervisor switching CPUs during the test)
-  * Succesfull full speed local bandwidth test is highly recommended prior to putting the VM into production
+    * Full-node VM is strongly preferred, having 2 VMs (latency/bandwidth node) on a single bare metal. Mixing perfSONAR VM(s) with others might have an impact on the measurements and is therefore not recommended.
+    * VM needs to be configured to have SR-IOV to NIC(s) as well as pinned CPUs to ensure bandwidth tests are not impacted (by hypervisor switching CPUs during the test)
+    * Succesfull full speed local bandwidth test is highly recommended prior to putting the VM into production
 * **Container** - perfSONAR has supported containers from version 4.1 (Q1 2018) and is documented at <https://docs.perfsonar.net/install_docker.html> but is not typically used in the same way as a full toolkit installation.
-  * Docker perfSONAR test instance can however still be used by sites that run multiple perfSONAR instances on site for their internal testing as this deployment model allows to flexibly deploy a testpoint which can send results to a local measurement archive running on the perfSONAR toolkit node.
+    * Docker perfSONAR test instance can however still be used by sites that run multiple perfSONAR instances on site for their internal testing as this deployment model allows to flexibly deploy a testpoint which can send results to a local measurement archive running on the perfSONAR toolkit node.
 
 ### perfSONAR Toolkit vs Testpoint
 
 The perfSONAR team has documented the types of installations supported at <https://docs.perfsonar.net/install_options.html>.   With the release of version 5, OSG/WLCG sites have a new option: instead of installing the full Toolkit sites can choose to install the Testpoint bundle.
 
-* Pros
-  * Simpler deployment when a local web interface is not needed and a central measurement archive is available.
-  * Less resource intensive for both memory and I/O capacity.
-* Cons
-  * Measurements are not stored locally
-  * No web interface to use for configuration or adding local tests
-  * Unable to show results in MaDDash
+  * Pros
+    * Simpler deployment when a local web interface is not needed and a central measurement archive is available.
+    * Less resource intensive for both memory and I/O capacity.
+  * Cons
+    * Measurements are not stored locally
+    * No web interface to use for configuration or adding local tests
+    * Unable to show results in MaDDash
 
 While sites are free to choose whatever deployment method they want, we would like to strongly recommend the use of perfSONAR's containerized testpoint. This method was chosen as a "best practice" recommendation because of the reduced resource constraints, less components and easier management.
 

docs/perfsonar/installation.md

@@ -35,7 +35,7 @@ The following *additional* steps are needed to configure the toolkit to be used
 * Please register your nodes in GOCDB/OIM. For OSG sites, follow the details in OSG Topology below. For non-OSG sites, follow the details in [GOCDB](#register-perfsonar-service-in-gocdb)
 * Please ensure you have added or updated your [administrative information](http://docs.perfsonar.net/manage_admin_info.html)
 * You will need to configure your instance(s) to use the OSG/WLCG mesh-configuration. Please follow the steps below:
-  * **For toolkit versions 5.0 and higher**, please run from the command line `psconfig remote add https://psconfig.opensciencegrid.org/pub/auto/<FQDN>`. Replace `<FQDN>` with the fully qualified domain name of your host, e.g., `psum01.aglt2.org`. To verify the configuration is correct, you can run `psconfig remote list`, which should show the URL configured, e.g.
+    * **For toolkit versions 5.0 and higher**, please run from the command line `psconfig remote add https://psconfig.opensciencegrid.org/pub/auto/<FQDN>`. Replace `<FQDN>` with the fully qualified domain name of your host, e.g., `psum01.aglt2.org`. To verify the configuration is correct, you can run `psconfig remote list`, which should show the URL configured, e.g.
 
  ```json
  === pScheduler Agent ===
@@ -46,7 +46,6 @@ The following *additional* steps are needed to configure the toolkit to be used
     }
  ]
  ```
-
 * Please remove any old/stale URLs using `psconfig remote delete <URL>`
 
 * If this is a **new instance** or you have changed the node's FQDN, you will need to notify `wlcg-perfsonar-support 'at' cern.ch` to add/update the hostname in one or more test meshes, which will then auto-configure the tests. Please indicate if you have preferences for which meshes your node should be included in (USATLAS, USCMS, ATLAS, CMS, LHCb, Alice, BelleII, etc.). You could also add any additional local tests  via web interface (see [Configuring regular tests](http://docs.perfsonar.net/manage_regular_tests.html) for details). Please check which tests are auto-added via central meshes before adding any custom tests to avoid duplication.
@@ -97,11 +96,11 @@ You might not be able to access the page if you are not properly registered in G
 
 * There are two service types for perfSONAR: net.perfSONAR.Bandwidth and net.perfSONAR.Latency. This is because we suggest t install two perfSONAR boxes at the site (one for latency tests and one for bandwidth tests) and therefore two distinct service endpoints should be published with two distinct service types. If the site can not afford sufficient hardware for the proposed setup, it can install a unique perfSONAR box, but still should publish both services types (with the same host in the "host name" field of the form).
 * For each form (i.e. for each service type) fill at least the important informations:
-* Hosting Site (drop-down menu, mandatory)
-* Service Type (drop-down menu, mandatory)
-* Host Name (free text, mandatory)
-* Host IP (free text, optional)
-* Description: (free text, optional) This field has a default value of your site name. It is used to "Label" your host in our MaDDash GUI. If you want to use this field please use something as short as possible uniquely identifying this instance.
+    * Hosting Site (drop-down menu, mandatory)
+    * Service Type (drop-down menu, mandatory)
+    * Host Name (free text, mandatory)
+    * Host IP (free text, optional)
+    * Description: (free text, optional) This field has a default value of your site name. It is used to "Label" your host in our MaDDash GUI. If you want to use this field please use something as short as possible uniquely identifying this instance.
 * Check "N" when asked "Is it a beta service"
 * Check "Y" when asked "Is this service in production"
 * Check "Y" when asked "Is this service monitored"