Fix: Resolve CI test errors for pull request apache#149

This commit addresses various CI test failures identified in pull request apache#149.
The following issues have been resolved:

- Markdown linting errors: Corrected capitalization, list formatting, and blank line issues in several documentation files.
- Sidebar configuration errors: Added missing  files with appropriate frontmatter (sidebar_label, sidebar_position, DocCardList import/tag) to ensure correct sidebar generation.
- YAML linting: Manually verified YAML files for correct syntax, as automated linting was unavailable.

These changes aim to bring the documentation in line with project standards and pass CI checks.

Author: jojochuang

docs/03-core-concepts/01-architecture.md

@@ -82,7 +82,7 @@ The OM is the entry point for all namespace operations. It tracks which objects
 
 ### Storage Container Manager (SCM)
 
-The Storage Container Manager orchestrates the container lifecycle and coordinates datanodes:
+The Storage Container Manager orchestrates the container lifecycle and coordinates Datanodes:
 
 - Manages container creation and allocation
 - Tracks datanode status and health
@@ -103,7 +103,7 @@ Datanodes are the workhorses that store the actual data:
 - Participate in replication pipelines
 - Handle data integrity checks
 
-Each datanode manages a set of containers and serves read/write requests from clients.
+Each Datanode manages a set of containers and serves read/write requests from clients.
 
 ### Recon
 
@@ -145,9 +145,9 @@ The Ozone client is the software component that enables applications to interact
 
 - Provides Java libraries for programmatic access
 - Handles communication with OM for namespace operations
-- Manages direct data transfer with datanodes
+- Manages direct data transfer with Datanodes
 - Implements client-side caching for improved performance
-- Offers pluggable interfaces for different protocols (S3, OFS)
+- Offers pluggable interfaces for different protocols (S3, ofs)
 - Handles authentication and token management
 
 The client library abstracts away the complexity of the distributed system, providing applications with a simple, consistent interface to Ozone storage.
@@ -178,7 +178,9 @@ For reads, the process is simpler:
 #### Monitoring and Management
 
 ![Diagram showing Recon collecting data from OM, SCM, and Datanodes for monitoring.](../../static/img/ozone/recon.svg)
+
 The Recon service continuously:
+
 - Collects metrics from the Ozone Manager, Storage Container Manager, and Datanodes
 - Provides consolidated views of system health and performance
 - Facilitates troubleshooting and management
@@ -193,7 +195,7 @@ Containers are the fundamental storage units in Ozone:
 
 - Fixed-size (typically 5GB) units of storage
 - Managed by the Storage Container Manager (SCM)
-- Replicated or erasure-coded across datanodes
+- Replicated or erasure-coded across Datanodes
 - Contain multiple blocks
 - Include metadata and chunk files
 
@@ -209,7 +211,7 @@ Blocks are logical units of data within containers:
 - Allocated by the Ozone Manager
 - Secured with block tokens
 
-When a client writes data, the OM allocates blocks from SCM, and the client writes data to these blocks through datanodes.
+When a client writes data, the OM allocates blocks from SCM, and the client writes data to these blocks through Datanodes.
 
 ### Chunks
 
@@ -230,34 +232,34 @@ Ozone provides durability through container replication:
 
 - Default replication factor is 3
 - Uses Ratis (Raft) consensus protocol
-- Synchronously replicates data across datanodes
+- Synchronously replicates data across Datanodes
 - Provides strong consistency guarantees
 - Handles node failures transparently
 
-Replicated containers ensure data durability by storing multiple copies of each container across different datanodes.
+Replicated containers ensure data durability by storing multiple copies of each container across different Datanodes.
 
-![Diagram illustrating how data blocks and chunks are stored across datanodes in a replicated container setup.](../../static/img/ozone/ozone-storage-hierarchy-replicated.svg)
+![Diagram illustrating how data blocks and chunks are stored across Datanodes in a replicated container setup.](../../static/img/ozone/ozone-storage-hierarchy-replicated.svg)
 
 ### Erasure Encoded Containers
 
 Erasure coding provides space-efficient durability:
 
-- Splits data across multiple datanodes with parity
+- Splits data across multiple Datanodes with parity
 - Supports various coding schemes (e.g., RS-3-2-1024k)
 - Reduces storage overhead compared to replication
 - Trades some performance for storage efficiency
 - Suitable for cold data storage
 
 Erasure coding allows for data durability with less storage overhead than full replication.
 
-![Diagram illustrating how data and parity blocks are stored across datanodes in an erasure coded container setup.](../../static/img/ozone/ozone-storage-hierarchy-ec.svg)
+![Diagram illustrating how data and parity blocks are stored across Datanodes in an erasure coded container setup.](../../static/img/ozone/ozone-storage-hierarchy-ec.svg)
 
 ### Pipelines
 
-Pipelines are groups of datanodes that work together to store data:
+Pipelines are groups of Datanodes that work together to store data:
 
 - Managed by SCM
-- Consist of multiple datanodes
+- Consist of multiple Datanodes
 - Handle write operations as a unit
 - Support different replication strategies
 
@@ -267,7 +269,7 @@ For detailed information, see [Write Pipelines](./02-data-replication/02-write-p
 
 Ratis pipelines use the Raft consensus protocol:
 
-- Typically three datanodes per pipeline
+- Typically three Datanodes per pipeline
 - One leader and multiple followers
 - Synchronous replication
 - Strong consistency guarantees
@@ -292,7 +294,7 @@ Ozone supports multiple access protocols, making it versatile for different appl
 - Full feature access
 - Highest performance
 
-### Ozone File System (OFS)
+### Ozone File System (ofs)
 
 - Hadoop-compatible filesystem interface
 - Works with all Hadoop ecosystem applications
@@ -310,6 +312,7 @@ Ozone supports multiple access protocols, making it versatile for different appl
 - Enables web applications to access Ozone
 - Path format: `http://httpfs-host/webhdfs/v1/volume/bucket/key`
 
+
 The multi-protocol architecture allows for flexible integration with existing applications and workflows.
 
 ## Summary

docs/03-core-concepts/01-namespace/01-volumes/02-owners.md

@@ -14,10 +14,10 @@ Ownership is a fundamental aspect of Ozone volumes that determines who has admin
 - In secure clusters, ownership is tied to authentication mechanisms like Kerberos
 - Volume ownership enables delegation of administrative responsibilities
 - Only the volume owner and Ozone administrators can perform certain operations like:
-    - Creating buckets within the volume
-    - Setting volume properties
-    - Modifying volume quotas
-    - Deleting the volume
+  - Creating buckets within the volume
+  - Setting volume properties
+  - Modifying volume quotas
+  - Deleting the volume
 
 ### Ozone Administrators
 
@@ -60,4 +60,4 @@ ozone sh volume list /
 
 # Change the owner of an existing volume (requires current owner or admin privileges)
 ozone sh volume update --user=new-owner /marketing
-```
+```

docs/03-core-concepts/01-namespace/01-volumes/03-quotas.md

@@ -4,7 +4,6 @@ sidebar_label: Quotas
 
 # Volume Quotas
 
-
 ## Quota Management
 
 Quotas provide a mechanism to control resource utilization at the volume level:
@@ -29,4 +28,4 @@ ozone sh volume clrquota --space /marketing
 
 # Clear the namespace quota (set object count limit to unlimited)
 ozone sh volume clrquota --count /marketing
-```
+```

docs/03-core-concepts/01-namespace/02-buckets/02-owners.md

@@ -8,14 +8,14 @@ Every bucket in Apache Ozone has an **owner**. The owner is typically the user w
 
 ## Significance of Ownership
 
-*   **Default Permissions:** The owner of a bucket implicitly has full control (ALL permissions) over the bucket itself, including the ability to modify its properties (like quotas, versioning) and delete it.
-*   **ACL Management:** The owner (or an Ozone administrator) is usually responsible for managing the Access Control Lists (ACLs) for the bucket, granting permissions to other users or groups.
-*   **Quota Accountability:** While quotas are set on the bucket itself, ownership can be relevant for tracking resource usage back to a specific user or tenant, especially in multi-tenant environments where volumes might represent tenants and buckets represent applications or projects within that tenant.
+- **Default Permissions:** The owner of a bucket implicitly has full control (ALL permissions) over the bucket itself, including the ability to modify its properties (like quotas, versioning) and delete it.
+- **ACL Management:** The owner (or an Ozone administrator) is usually responsible for managing the Access Control Lists (ACLs) for the bucket, granting permissions to other users or groups.
+- **Quota Accountability:** While quotas are set on the bucket itself, ownership can be relevant for tracking resource usage back to a specific user or tenant, especially in multi-tenant environments where volumes might represent tenants and buckets represent applications or projects within that tenant.
 
 ## Determining the Owner
 
-*   **Creation Time:** When a bucket is created, the user principal making the creation request (authenticated via Kerberos, token, etc.) is typically set as the owner.
-*   **Inheritance (S3 Interface):** When creating buckets via the S3 gateway, the owner might be determined differently based on the S3 multi-tenancy configuration. In some setups, the owner might be mapped from the S3 access key or assumed role.
+- **Creation Time:** When a bucket is created, the user principal making the creation request (authenticated via Kerberos, token, etc.) is typically set as the owner.
+- **Inheritance (S3 Interface):** When creating buckets via the S3 Gateway, the owner might be determined differently based on the S3 multi-tenancy configuration. In some setups, the owner might be mapped from the S3 access key or assumed role.
 
 ## Viewing the Owner
 
@@ -31,4 +31,4 @@ The output will include an `owner` field displaying the user principal who owns
 
 Changing the owner of a bucket after creation is generally **not** a standard user operation in Ozone and typically requires administrative privileges or specific tooling, depending on the deployment and security configuration. Ownership is primarily established at creation time.
 
-Understanding bucket ownership is important for managing permissions and accountability within the Ozone namespace.
+Understanding bucket ownership is important for managing permissions and accountability within the Ozone namespace.

docs/03-core-concepts/01-namespace/02-buckets/03-quotas.md

@@ -10,16 +10,16 @@ Apache Ozone allows administrators or bucket owners to set **quotas** on buckets
 
 Ozone supports two types of quotas at the bucket level:
 
-1.  **Namespace Quota:**
-    *   Limits the total number of **keys** (objects, files, directories) that can exist within the bucket.
-    *   Helps control the size of the Ozone Manager's metadata.
-    *   Expressed as a simple count (e.g., 1,000,000 keys).
+- **Namespace Quota:**
+  - Limits the total number of **keys** (objects, files, directories) that can exist within the bucket.
+  - Helps control the size of the Ozone Manager's metadata.
+  - Expressed as a simple count (e.g., 1,000,000 keys).
 
-2.  **Storage Space Quota:**
-    *   Limits the total **disk space** consumed by the data blocks of all objects within the bucket.
-    *   This limit applies to the logical size of the data *before* replication. For example, a 1 GB object will count as 1 GB towards the quota, regardless of whether it's replicated 3 times (consuming 3 GB physically) or uses erasure coding.
-    *   Helps control the overall physical storage usage.
-    *   Expressed in bytes, often using units like KB, MB, GB, TB, PB (e.g., `100GB`, `1TB`).
+- **Storage Space Quota:**
+  - Limits the total **disk space** consumed by the data blocks of all objects within the bucket.
+  - This limit applies to the logical size of the data *before* replication. For example, a 1 GB object will count as 1 GB towards the quota, regardless of whether it's replicated 3 times (consuming 3 GB physically) or uses erasure coding.
+  - Helps control the overall physical storage usage.
+  - Expressed in bytes, often using units like KB, MB, GB, TB, PB (e.g., `100GB`, `1TB`).
 
 ## Setting Quotas
 
@@ -46,13 +46,13 @@ ozone sh bucket setquota --quota 500GB /vol1/limited-bucket
 ozone sh bucket setquota --quota -1 --namespace-quota 5000000 /vol1/limited-bucket
 ```
 
-*   Use `-1` or `none` to remove a specific quota limit.
+- Use `-1` or `none` to remove a specific quota limit.
 
 ## Enforcement
 
-*   When a write operation (creating an object, uploading data) would cause a bucket to exceed its quota, the operation will fail.
-*   Namespace quota is checked when creating new keys.
-*   Space quota is checked based on the size of the data being written.
+- When a write operation (creating an object, uploading data) would cause a bucket to exceed its quota, the operation will fail.
+- Namespace quota is checked when creating new keys.
+- Space quota is checked based on the size of the data being written.
 
 ## Viewing Quotas
 
@@ -64,4 +64,4 @@ ozone sh bucket info /volumeName/bucketName
 
 The output will show fields like `quotaInBytes`, `quotaInNamespace`, `usedBytes`, and `usedNamespace`.
 
-Bucket quotas are a fundamental tool for managing storage resources effectively in Ozone.
+Bucket quotas are a fundamental tool for managing storage resources effectively in Ozone.

docs/03-core-concepts/01-namespace/02-buckets/04-layouts/01-object-store.md

@@ -8,21 +8,21 @@ The **Object Store (OBS)** layout is one of the modern bucket layouts in Apache
 
 ## Key Characteristics
 
-*   **Flat Namespace:** Unlike the [File System Optimized (FSO)](./02-file-system-optimized.md) layout, OBS does not simulate a hierarchical directory structure internally. Keys are stored directly within the bucket. While delimiters like `/` can be used in key names (e.g., `images/archive/photo.jpg`) for organizational purposes (as commonly interpreted by S3 clients), Ozone treats the entire string as the unique object key. There are no separate directory entries maintained by Ozone itself.
-*   **Strict S3 Compatibility:** OBS is the recommended layout for workloads demanding the highest fidelity with the Amazon S3 API and its object storage semantics. Cloud-native applications built using AWS SDKs, Boto3, or other S3 client libraries can interact with OBS buckets seamlessly.
-*   **OFS/HCFS Incompatibility:** Buckets created with the OBS layout **cannot** be accessed using Hadoop Compatible File System (HCFS) protocols like `ofs://` or `o3fs://`. Attempting filesystem operations (like creating directories or listing files using Hadoop FS APIs) on an OBS bucket will fail.
-*   **Use Cases:** Ideal for:
-    *   **Cloud-Native Applications:** Applications built using S3 SDKs (AWS SDK, Boto3, etc.) expecting standard S3 behavior.
-    *   **Unstructured Data:** Storing large amounts of unstructured or semi-structured data like images, videos, audio files, sensor data, logs, backups, and archives where hierarchical filesystem access is not the primary requirement.
-    *   **S3 Compatibility:** Workloads requiring the highest fidelity with the S3 API and object storage semantics.
-    *   **Data Exploration:** Enabling exploration of unstructured data using S3-compatible tools.
-    *   It's the preferred choice when filesystem semantics (like atomic directory renames) are not required.
-*   **Performance:** Optimized for typical object storage operations.
+- **Flat Namespace:** Unlike the [File System Optimized (FSO)](./02-file-system-optimized.md) layout, OBS does not simulate a hierarchical directory structure internally. Keys are stored directly within the bucket. While delimiters like `/` can be used in key names (e.g., `images/archive/photo.jpg`) for organizational purposes (as commonly interpreted by S3 clients), Ozone treats the entire string as the unique object key. There are no separate directory entries maintained by Ozone itself.
+- **Strict S3 Compatibility:** OBS is the recommended layout for workloads demanding the highest fidelity with the Amazon S3 API and its object storage semantics. Cloud-native applications built using AWS SDKs, Boto3, or other S3 client libraries can interact with OBS buckets seamlessly.
+- **ofs/HCFS Incompatibility:** Buckets created with the OBS layout **cannot** be accessed using Hadoop Compatible File System (HCFS) protocols like `ofs://` or `o3fs://`. Attempting filesystem operations (like creating directories or listing files using Hadoop FS APIs) on an OBS bucket will fail.
+- **Use Cases:** Ideal for:
+  - **Cloud-Native Applications:** Applications built using S3 SDKs (AWS SDK, Boto3, etc.) expecting standard S3 behavior.
+  - **Unstructured Data:** Storing large amounts of unstructured or semi-structured data like images, videos, audio files, sensor data, logs, backups, and archives where hierarchical filesystem access is not the primary requirement.
+  - **S3 Compatibility:** Workloads requiring the highest fidelity with the S3 API and object storage semantics.
+  - **Data Exploration:** Enabling exploration of unstructured data using S3-compatible tools.
+  - It's the preferred choice when filesystem semantics (like atomic directory renames) are not required.
+- **Performance:** Optimized for typical object storage operations.
 
 ## Multi-Protocol Access Considerations
 
-*   **S3 Access:** This is the primary and intended access method for OBS buckets.
-*   **OFS/o3fs Access:** Not supported.
+- **S3 Access:** This is the primary and intended access method for OBS buckets.
+- **ofs/o3fs Access:** Not supported.
 
 ## Creating OBS Buckets