[YUNIKORN-2900] solve broken anchors

Fix the broken anchor and some minor spacing issues in the text.
Leaving 1.6.3 updates as part of this change.

Closes: #525

Signed-off-by: hhcs9527 <hhcs9527@gmail.com>
Signed-off-by: Wilfred Spiegelenburg <wilfreds@apache.org>

Author: pohanhuang

docs/api/system.md

@@ -66,7 +66,7 @@ Note that this list is not guaranteed to remain stable and can change from relea
 
 **Content examples**
 
-The output of this REST query can be rather large, and it is a combination of those which have already been documented as part of the [scheduler API](scheduler.md#Overview).
+The output of this REST query can be rather large, and it is a combination of those which have already been documented as part of the [scheduler API](scheduler.md).
 
 The `RMDiagnostics` shows the content of the K8Shim cache. The exact content is version dependent and is not stable.
 The current content shows the cached objects:
@@ -81,7 +81,7 @@ The current content shows the cached objects:
 
 ## Go routine info
 
-Dumps the stack traces of the currently running goroutines. This is a similar view as provided in the [pprof goroutine](#pprof-goroutine) in a human-readable form.  
+Dumps the stack traces of the currently running goroutines. This is a similar view as provided in the [pprof goroutine](#pprof-goroutine) in a human-readable form.
 
 **URL** : `/debug/stack`
 
@@ -317,7 +317,7 @@ trace: A trace of execution of the current program. You can specify the duration
 num_symbols: 1
 ```
 
-## pprof trace		
+## pprof trace
 
 **URL** : `/debug/pprof/trace`
 

docs/archived_design/k8shim.md

@@ -55,7 +55,7 @@ and a [validation webhook](https://kubernetes.io/docs/reference/access-authn-aut
        to immediately transition from the `Starting` to `Running` state so that it will not block other applications.
 2. The `validation webhook` validates the configuration set in the configmap
    - This is used to prevent writing malformed configuration into the configmap.
-   - The validation webhook calls scheduler [validation REST API](api/scheduler.md#configuration-validation) to validate configmap updates.
+   - The validation webhook calls scheduler [validation REST API](api/cluster.md#configuration-validation) to validate configmap updates.
 
 ### Admission controller deployment
 
@@ -66,7 +66,7 @@ On startup, the admission controller performs a series of tasks to ensure that i
 2. If the secret cannot be found or either CA certificate is within 90 days of expiration, generates new certificate(s). If a certificate is expiring, a new one is generated with an expiration of 12 months in the future. If both certificates are missing or expiring, the second certificate is generated with an expiration of 6 months in the future. This ensures that both certificates do not expire at the same time, and that there is an overlap of trusted certificates.
 3. If the CA certificates were created or updated, writes the secrets back to Kubernetes.
 4. Generates an ephemeral TLS server certificate signed by the CA certificate with the latest expiration date.
-5. Validates, and if necessary, creates or updates the Kubernetes webhook configurations named `yunikorn-admission-controller-validations` and `yunikorn-admission-controller-mutations`. If the CA certificates have changed, the webhooks will also be updated. These webhooks allow the Kubernetes API server to connect to the admission controller service to perform configmap validations and pod mutations. 
+5. Validates, and if necessary, creates or updates the Kubernetes webhook configurations named `yunikorn-admission-controller-validations` and `yunikorn-admission-controller-mutations`. If the CA certificates have changed, the webhooks will also be updated. These webhooks allow the Kubernetes API server to connect to the admission controller service to perform configmap validations and pod mutations.
 6. Starts up the admission controller HTTPS server.
 
 Additionally, the admission controller also starts a background task to wait for CA certificates to expire. Once either certificate is expiring within the next 30 days, new CA and server certificates are generated, the webhook configurations are updated, and the HTTPS server is quickly restarted. This ensures that certificates rotate properly without downtime.

docs/design/gang_scheduling.md

@@ -167,15 +167,15 @@ For gang scheduling we have a simple one new to one release relation in the case
 
 The scheduler processes the AllocationAsk as follows:
 1. Check if the application has an unreleased allocation for a placeholder allocation with the same _taskGroupName._ If no placeholder allocations are found a normal allocation cycle will be used to allocate the request.
-2. A placeholder allocation is selected and marked for release. A request to release the placeholder allocation is communicated to the shim. This must be an async process as the shim release process is dependent on the underlying K8s response which might not be instantaneous.  
+2. A placeholder allocation is selected and marked for release. A request to release the placeholder allocation is communicated to the shim. This must be an async process as the shim release process is dependent on the underlying K8s response which might not be instantaneous.
    NOTE: no allocations are released in the core at this point in time.
-3. The core “parks” the processing of the real AllocationAsk until the shim has responded with a confirmation that the placeholder allocation has been released.  
+3. The core “parks” the processing of the real AllocationAsk until the shim has responded with a confirmation that the placeholder allocation has been released.
    NOTE: locks are released to allow scheduling to continue
 4. After the confirmation of the release is received from the shim the “parked” AllocationAsk processing is finalised.
 5. The AllocationAsk is allocated on the same node as the placeholder used.
    The removal of the placeholder allocation is finalised in either case. This all needs to happen as one update to the application, queue and node.
     * On success: a new Allocation is created.
-    * On Failure: try to allocate on a different node, if that fails the AllocationAsk becomes unschedulable triggering scale up. 
+    * On Failure: try to allocate on a different node, if that fails the AllocationAsk becomes unschedulable triggering scale up.
 6. Communicate the allocation back to the shim (if applicable, based on step 5)
 
 ## Application completion
@@ -196,7 +196,7 @@ The time out of the _waiting_ state is new functionality.
 
 Placeholders are not considered active allocations.
 Placeholder asks are considered pending resource asks.
-These cases will be handled in the [Cleanup](#Cleanup) below.
+These cases will be handled in the [Cleanup](#cleanup) below.
 
 ### Cleanup
 When we look at gang scheduling there is a further issue around unused placeholders, placeholder asks and their cleanup.
@@ -219,7 +219,7 @@ Processing in the core thus needs to consider two cases that will impact the tra
 1. Placeholder asks pending (exit from _accepted_)
 2. Placeholders allocated (exit from _waiting_)
 
-Placeholder asks pending:  
+Placeholder asks pending:
 Pending placeholder asks are handled via a timeout.
 An application must only spend a limited time waiting for all placeholders to be allocated.
 This timeout is needed because an application’s partial placeholders allocation may occupy cluster resources without really using them.
@@ -259,7 +259,7 @@ Combined flow for the shim and core during timeout of placeholder:
 *   After the placeholder Allocations and Asks are released the core moves the application to the killed state removing it from the queue (4).
 *   The state change is finalised in the core and shim. (5)
 
-Allocated placeholders:  
+Allocated placeholders:
 Leftover placeholders need to be released by the core.
 The shim needs to be informed to remove them. This must be triggered on entry of the _completed_ state.
 After the placeholder release is requested by the core the state transition of the application can proceed.
@@ -429,14 +429,14 @@ In patched message form that would look like:
 message UpdateResponse {
 ...
   // Released allocation(s), allocations can be released by either the RM or scheduler.
-  // The TerminationType defines which side needs to act and process the message. 
+  // The TerminationType defines which side needs to act and process the message.
   repeated AllocationRelease releasedAllocations = 3;
 ...
 }
 
 message AllocationReleasesRequest {
   // Released allocation(s), allocations can be released by either the RM or scheduler.
-  // The TerminationType defines which side needs to act and process the message. 
+  // The TerminationType defines which side needs to act and process the message.
   repeated AllocationRelease releasedAllocations = 1;
 ...
 }
@@ -469,7 +469,7 @@ In patched message form that would look like:
 message AllocationRelease {
   enum TerminationType {
     STOPPED_BY_RM = 0;
-    TIMEOUT = 1; 
+    TIMEOUT = 1;
     PREEMPTED_BY_SCHEDULER = 2;
     PLACEHOLDER_REPLACED = 3;
   }
@@ -481,7 +481,7 @@ message AllocationRelease {
   // The UUID of the allocation to release, if not set all allocations are released for
   // the applicationID
   string UUID = 3;
-  // The termination type as described above 
+  // The termination type as described above
   TerminationType terminationType = 4;
   // human-readable message
   string message = 5;
@@ -525,7 +525,7 @@ message AllocationReleasesRequest {
 ...
   // Released allocationask(s), allocationasks can be released by either the RM or
   // scheduler. The TerminationType defines which side needs to act and process the
-  // message. 
+  // message.
   repeated AllocationAskRelease allocationAsksToRelease = 2;
 }
 ```
@@ -536,12 +536,12 @@ In patched message form that would look like:
 message AllocationAskRelease {
   enum TerminationType {
     STOPPED_BY_RM = 0;
-    TIMEOUT = 1; 
+    TIMEOUT = 1;
     PREEMPTED_BY_SCHEDULER = 2;
     PLACEHOLDER_REPLACED = 3;
   }
 ...
-  // The termination type as described above 
+  // The termination type as described above
   TerminationType terminationType = 4;
 ...
 }

docs/design/scheduler_configuration.md

@@ -54,7 +54,7 @@ Configuration to consider:
 ## Queue Configuration
 ### Queue Definition
 On startup the scheduler will load the configuration for the queues from the provided configuration file after initialising the service. If there is no queue configuration provided the scheduler should start up with a simple default configuration which performs a well documented default behaviour.
-Based on the kubernetes definition this configuration could be a configMap <sup id="s1">[1](#f1)</sup> but not a CRD.
+Based on the kubernetes definition this configuration could be a [configMap](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#should-i-use-a-configmap-or-a-custom-resource) but not a CRD.
 
 The queue configuration is dynamic. Changing the queue configuration must not require a scheduler restart.
 Changes should be allowed by either calling the GO based API, the REST based API or by updating the configuration file. Changes made through the API must be persisted in the configuration file. Making changes through an API is not a high priority requirement and could be postponed to a later release.
@@ -166,7 +166,7 @@ Defining placement rules in the configuration requires the following information
     * Create (boolean)
 * Filter:
     * A regular expression or list of users/groups to apply the rule to.
-  
+
 The filter can be used to allow the rule to be used (default behaviour) or deny the rule to be used. User or groups matching the filter will be either allowed or denied.
 The filter is defined as follow:
 * Type:
@@ -213,7 +213,7 @@ Base point to make: a changed configuration should not impact the currently runn
 ### Access Control Lists
 The scheduler ACL is independent of the queue ACLs. A scheduler administrator is not by default allowed to submit an application or administer the queues in the system.
 
-All ACL types should use the same definition pattern. We should allow at least POSIX user and group names which uses the portable filename character set <sup id="s2">[2](#f2)</sup>. However we should take into account that we could have domain specifiers based on the environment that the system runs in (@ sign as per HADOOP-12751).
+All ACL types should use the same definition pattern. We should allow at least POSIX user and group names which uses the portable filename character set <a href="#footnote1"><sup>[1]</sup></a>. However we should take into account that we could have domain specifiers based on the environment that the system runs in (@ sign as per HADOOP-12751).
 
 By default access control is enabled and access is denied. The only special case is for the core scheduler which automatically adds the system user, the scheduler process owner, to the scheduler ACL. The scheduler process owner is allowed to make sure that the process owner can use the API to call any administrative actions.
 
@@ -241,6 +241,7 @@ The full configuration of the K8s shim is still under development.
 The full configuration of the YARN shim is still under development.
 
 ---
-<br/><b id="f1"></b>1: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#should-i-use-a-configmap-or-a-custom-resource. [↩](#s1)
-<br/><b id="f2"></b>2: The set of characters from which portable filenames are constructed. [↩](#s2)
-<br/>`A B C D E F G H I J K L M N O P Q R S T U V W X Y Z a b c d e f g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9 . _ -`
+<p id="footnote1">
+<strong>1.</strong> The set of characters from which portable filenames are constructed.<br/>
+<code>A B C D E F G H I J K L M N O P Q R S T U V W X Y Z a b c d e f g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9 . _ -</code>
+</p>

docs/developer_guide/dependencies.md

@@ -47,8 +47,8 @@ require (
 )
 ```
 Release branches **must** not use pseudo versions.
-During the creation of a release, [tags](/community/release_procedure#tag-and-update-release-for-version) will be created.
-These tags will be used as the reference in the go.mod files for the release.    
+During the creation of a release, [tags](/community/release_procedure#tag-for-release) will be created.
+These tags will be used as the reference in the go.mod files for the release.
 
 ## Enforcement of pseudo version
 In the pull request checks for the `yunikorn-core` and `yunikorn-k8shim` repositories enforce the format of the versions.
@@ -57,7 +57,7 @@ repositories in the `master` branch is not a pseudo version.
 
 The check enforces that the start of the version reference is `v.0.0.0-`
 
-Pseudo versions are not enforced in the release branches as per [why a pseudo version](#why-a-pseudo-version) explanation above. 
+Pseudo versions are not enforced in the release branches as per [why a pseudo version](#why-a-pseudo-version) explanation above.
 
 ## Updating the core dependency
 Before updating the core dependency must make sure that the scheduler interface changes are finalised.
@@ -100,7 +100,7 @@ It is therefor that steps 5 and 8 are performed to make sure there is no regress
 ## Generating a pseudo version
 
 A pseudo references for use in a go.mod file is based on the commit hash and timestamp.
-It is simple to generate one using the following steps: 
+It is simple to generate one using the following steps:
 
 1. Change to the repository for which the new pseudo version needs to be generated.
 2. Update the local checked out code for the master branch to get the latest commits