Improve usage doc, fix typos and follow style guide

Author: Rohit-0505

docs/baremetal/index.md

@@ -7,14 +7,14 @@ in a Kubernetes-native way. It leverages the power of Kubernetes Custom Resource
 - **Provisioning**: Deploy and configure servers using Ignition.
 - **Day-2 Operations**: Manage BIOS, firmware, and hardware inventory declaratively.
 - **3rd Party Integrations**: Seamlessly integrate with existing tools like vendor-specific management tools.
-- **Kubernetes Support**: Run Kubernetes on bare metal servers with support for Cluster API and Gardener.
+- **Kubernetes Support**: Run Kubernetes on bare metal servers with support of Cluster API and Gardener.
 
 ## Core Components
 
 The core components of the baremetal automation in IronCore include:
 - [**Metal Operator**](https://github.com/ironcore-dev/metal-operator): The central component that manages the lifecycle of bare metal servers.
 - [**Boot Operator**](https://github.com/ironcore-dev/boot-operator): iPXE and HTTP boot server that provides boot images and Ignition configurations.
-- [**FeDHCP**](https://github.com/ironcore-dev/fedhcp): A DHCP server that provides inband and out of band network configuration to bare metal servers.
+- [**FeDHCP**](https://github.com/ironcore-dev/fedhcp): A DHCP server that provides in-band and out-of-band network configuration to bare metal servers.
 
 ## Concepts and Usage Guides
 

docs/baremetal/kubernetes/gardener.md

@@ -4,14 +4,12 @@ Apart from the [Cluster API Provider for Bare Metal](/baremetal/kubernetes/capi)
 [Gardener](https://gardener.cloud), a Kubernetes-native project for managing Kubernetes clusters at scale.
 
 There are two main components in the Gardener integration with IronCore:
-- **Machine Controller Manager (MCM)**: This component is responsible for managing the lifecycle of machines in a 
-    Kubernetes cluster. It uses the `metal-operator` API types to provision and manage bare metal servers.
-- **Gardener Extension Provider**: This component provides the necessary integration points for Gardener to manage bare 
-    metal clusters.
+- **Machine Controller Manager (MCM)**: This component is responsible for managing the lifecycle of machines in a Kubernetes cluster. It uses the `metal-operator` API types to provision and manage bare metal servers.
+- **Gardener Extension Provider**: This component provides the necessary integration points for Gardener to manage bare metal clusters.
 
 ## Machine Controller Manager (MCM)
 
-The `[machine-controller-manager-provider-ironcore](https://github.com/ironcore-dev/machine-controller-manager-provider-ironcore-metal)`
+The [machine-controller-manager-provider-ironcore](https://github.com/ironcore-dev/machine-controller-manager-provider-ironcore-metal)
 is responsible for managing the lifecycle of `Nodes` in a Kubernetes cluster. Here the MCM in essence is translating
 Gardener `Machine` resource to `ServerClaims` and wrapping the `user-data` coming from the Gardner OS extensions into
 an Ignition `Secret`.
@@ -22,7 +20,7 @@ The [`gardener-extension-provider-ironcore-metal`](https://github.com/ironcore-d
 is responsible for providing the necessary integration points for Gardener to manage bare metal clusters.
 
 Those integration points include:
-- Configure and the [Cloud Controller Manager](/baremetal/kubernetes/cloud-controller-manager) to handle the `Node` lifecycle
+- Configure the [Cloud Controller Manager](/baremetal/kubernetes/cloud-controller-manager) to handle the `Node` lifecycle
 and topology information.
 - Configure the [metal-load-balancer-controller](/baremetal/kubernetes/metal-loadbalancer-controller) to handle `Service` of type `LoadBalancer`.
 - Configure the [Machine Controller Manager (MCM)](#machine-controller-manager-mcm) to manage the creation of `Nodes` in the cluster.

docs/baremetal/kubernetes/metal-loadbalancer-controller.md

@@ -4,18 +4,15 @@ The [metal-loadbalancer-controller](https://github.com/ironcore-dev/metal-load-b
 for managing the lifecycle of `Services` of type `LoadBalancer` in a Kubernetes cluster running on bare metal servers.
 The project consists of two main components: 
 - **Controller**: The main component that watches for changes in `Service` resources and manages the lifecycle of load balancers.
-- **Speaker**: Is responsible for announcing the load balancer IP address to `metalbond` which acts as a route reflector
-  to the bare metal servers. 
+- **Speaker**: Is responsible for announcing the load balancer IP address to `metalbond` which acts as a route reflector to the bare metal servers. 
 
 The `metal-loadbalancer-controller` is designed to work in an IPv6 only environment.
 
 ## Controller
 
 The controller component has the following responsibilities:
-- Watches for changes in `Service` resources of type `LoadBalancer` and uses the `ClusterIP` of a `Service` and patches the
-  `LoadBalancer` status using this `ClusterIP`.
-- Setting the `PodCIDRs` on the `Node` resources to ensure that the load balancer can route traffic to the pods. Here it 
-  takes the main `Node` IP address and the configured `node-cidr-mask-size` and patches the `Node.spec.podCIDRs` field.
+- Watches for changes in `Service` resources of type `LoadBalancer` and uses the `ClusterIP` of a `Service` and patches the `LoadBalancer` status using this `ClusterIP`.
+- Setting the `PodCIDRs` on the `Node` resources to ensure that the load balancer can route traffic to the pods. Here it takes the main `Node` IP address and the configured `node-cidr-mask-size` and patches the `Node.spec.podCIDRs` field.
 
 ## Metalbond-Speaker
 

docs/contribute/contributing.md

@@ -12,9 +12,6 @@ We welcome contributions from the community! Follow these guidelines to help us
 - Feedback will be provided if any adjustments are necessary.
 
 Thank you for helping improve our documentation!
-# Contributing to IronCore Documentation
-
-We welcome contributions from the community! Follow these guidelines to help us maintain high-quality, consistent documentation.
 ## Contributors Guide
 
 The IronCore Documentation project uses Github to manage reviews of pull requests.
@@ -36,11 +33,11 @@ and us a good deal of inspiration.
 
 ## Steps to Contribute
 
-Do you want to work on an issue?  You are welcome to claim an existing one by commenting on it in GitHub. 
+Do you want to work on an issue? You are welcome to claim an existing one by commenting on it in GitHub. 
 
 !!! note
     Perform a cursory search to see if the issue has already been taken by someone else. 
-    This will prevent misunderstanding and duplication of  effort from contributors on the same issue.
+    This will prevent misunderstanding and duplication of effort from contributors on the same issue.
 
 If you have questions about one of the issues please comment on them and one of the 
 maintainers will clarify it.
@@ -67,14 +64,14 @@ process. We use [the standard DCO text of the Linux Foundation](https://develope
 
 * Fork and clone the repository to your local machine.
 
-```shell
-git clone [email protected]:ironcore-dev/ironcore-dev.github.io.git
-cd docs
-```
+    ```shell
+    git clone [email protected]:ironcore-dev/ironcore-dev.github.io.git
+    cd docs
+    ```
 
-* Create a branch from the `main`  using 'git checkout' command. 
+* Create a branch from the `main` using 'git checkout' command. 
 !!! note 
-    If needed, rebase to the current `main` branch before submitting  your pull request. If it doesn't merge properly
+    If needed, rebase to the current `main` branch before submitting your pull request. If it doesn't merge properly
     with `main` you may be asked to rebase your changes.
 
     ```shell
@@ -86,13 +83,13 @@ cd docs
 
 * Commits should be as small as possible, while ensuring that each commit is correct independently 
 
-*  Commit your changes to your feature branch and push it to your fork.
+* Commit your changes to your feature branch and push it to your fork.
 
-```shell
-git add .
-git commit -m "Something meaningful"
-git push origin my_feature
-```
+    ```shell
+    git add .
+    git commit -m "Something meaningful"
+    git push origin my_feature
+    ```
 
 !!! note
     Alternatively you can amend your commit before pushing if you forgot something by using `git commit --amend`
@@ -111,7 +108,7 @@ for a review in the pull request or a comment.
 
 ## Issues and Planning
 
-We use GitHub issues to track bugs and enhancement requests. Please provide as much context as possible when you open  an issue. The information you provide must be comprehensive enough to understand, reproduce the behavior and find related reports of  that issue for the assignee. 
+We use GitHub issues to track bugs and enhancement requests. Please provide as much context as possible when you open an issue. The information you provide must be comprehensive enough to understand, reproduce the behavior and find related reports of that issue for the assignee. 
 Therefore, contributors may use but aren't restricted to the issue template provided by the IronCore maintainers.
 
 

docs/iaas/architecture/networking.md

@@ -14,23 +14,21 @@ IronCore's virtual networking architecture is illustrated with the following fig
 
 The main elements involved in IronCore's networking are:
 - [**ironcore**](https://github.com/ironcore-dev/ironcore): Core networking component that manages network resources and configurations. For more details, see the 
-  [Networking usage guide](/iaas/usage-guides/networking).
+[Networking usage guide](/iaas/usage-guides/networking).
 - [**ironcore-net**](https://github.com/ironcore-dev/ironcore-net): Global coordination service that manages network resource in an IronCore instance.
 - [**metalnet**](https://github.com/ironcore-dev/metalnet): A service that provides cluster-level networking capabilities for `Machines`.
 - [**dpservice**](https://github.com/ironcore-dev/dpservice): A service that manages data plane operations, including network traffic routing and policies.
 - [**metalbond**](https://github.com/ironcore-dev/metalbond): A component that handles route announcements in an IronCore instance, ensuring that networking routes are
-    correctly propagated across the IronCore installation.
+correctly propagated across the IronCore installation.
 
 ## `ironcore` and `ironcore-net`
 
 `ironcore-net` is a global coordination service within an IronCore installation. Therefore, it is a single instance and 
 the place where all network related decisions like reservation of unique IP addresses, allocation of unique network IDs, etc. are made.
 
 `ironcore-net` has apart from its [own API](https://github.com/ironcore-dev/ironcore-net/tree/main/api/core/v1alpha1) two main components:
-- **apinetlet**: This component is responsible from translating the user-facing API objects from the `networking` resource group into the 
-  internal representation used by `ironcore-net`. 
-- **metalnetlet**: This component is interfacing with the `metalnet` API to manage cluster-level networking resources like `NetworkInterface` which
-  are requested globally in the `ironcore-net` API but are implemented by `metalnet` on a hypervisor level.
+- **apinetlet**: This component is responsible from translating the user-facing API objects from the `networking` resource group into the internal representation used by `ironcore-net`. 
+- **metalnetlet**: This component is interfacing with the `metalnet` API to manage cluster-level networking resources like `NetworkInterface` which are requested globally in the `ironcore-net` API but are implemented by `metalnet` on a hypervisor level.
 
 ### Example `apinetlet` flow
 
@@ -50,10 +48,10 @@ The `apinetlet` will reconcile this `VirtualIP` by performing the following step
 1. Create an `IP` object in the `ironcore-net` API, which reserves a unique IP address.
 2. Update the `VirtualIP` status with the allocated IP address.
 
-The `ironcore` API server is agnostic on how the underlying global IP address is allocated and delegates this responsibility 
+The `IronCore` API server is agnostic on how the underlying global IP address is allocated and delegates this responsibility 
 to `ironcore-net`.
 
-A similar flow happens for `Networks`, `LoadBalancer` and `NatGateways` resources, where the `apinetlet` is responsible
+A similar flow happens for `Network`, `LoadBalancer` and `NatGateway` resources, where the `apinetlet` is responsible
 for translating and allocating the necessary resources in `ironcore-net` to ensure that the networking requirements are met.
 
 ### `metalnetlet` and `metalnet`

docs/iaas/architecture/runtime-interface.md

@@ -1,6 +1,6 @@
 # IronCore Runtime Interface (IRI)
 
-The IronCore Runtime Interface (IRI) is a key concept in the IronCore architecture, designed to provide a consitent
+The IronCore Runtime Interface (IRI) is a key concept in the IronCore architecture, designed to provide a consistent
 and unified interface for interacting with various compute and storage providers. The IRI abstracts the underlying 
 complexities of different providers.
 
@@ -12,7 +12,7 @@ There are three main runtime interfaces in IronCore:
 Implementations of these interfaces are done by provider-specific components. More infomation about the provider can
 be found in the [provider concept documentation](/iaas/architecture/providers/).
 
-The definition of the runtime interfaces can be found in IronCores [`iri` package](https://github.com/ironcore-dev/ironcore/tree/main/iri/).
+The definition of the runtime interfaces can be found in IronCore's [`iri` package](https://github.com/ironcore-dev/ironcore/tree/main/iri/).
 
 ## MachineRuntime Interface
 
@@ -40,9 +40,7 @@ service MachineRuntime {
 }
 ```
 
-The general idea is that a `machinepoollet` ensures that the API level dependencies are met. For example, a `Machine`s 
-`Volume` which is used as a root disk is in the state `Available`. If those prerequisites are met, the `poollet` will 
-call the corresponding `CreateMachine` method of the `RuntimeInterface` to create the `Machine` resource.
+The general idea is that a `machinepoollet` ensures that the API level dependencies are met. For example, a `Machine`'s `Volume` which is used as a root disk is in the state `Available`. If those prerequisites are met, the `poollet` will call the corresponding `CreateMachine` method of the `RuntimeInterface` to create the `Machine` resource.
 
 The `ListMachines` and `Status` methods are used to retrieve a list of all `Machine` instances managed by the provider. 
 The result of those methods is then used to propagate `Machine` state changes. Those methods are periodically called by 
@@ -53,7 +51,7 @@ methods to attach volumes or network interfaces to a `Machine` if a change in th
 
 ## VolumeRuntime Interface
 
-Similar to the `MachineRuntime`, the `VolumeRuntime` interface is responsible for managing storage resources in IronCore.
+Similar to the `MachineRuntime`, the `VolumeRuntime` interface is responsible for managing block storage resources in IronCore.
 Here the `volumepoollet` takes a similar role as the `machinepoollet` for the `MachineRuntime` and invokes `CreateVolume`,
 `DeleteVolume`, `ExpandVolume`, and other methods to manage `Volume` resources.
 

docs/iaas/kubernetes/cloud-controller-manager.md

@@ -27,10 +27,10 @@ Below is the detailed explanation on how APIs are implemented by `cloud-provider
 
 InstanceMetadata returns metadata of a node instance, which includes :
 
-- `ProviderID`:  Provider is combination of ProviderName(Which is nothing but set to `IronCore`)
-- `InstanceType`:  InstanceType is set to referencing MachineClass name by the instance.
+- `ProviderID`: Provider is combination of ProviderName(Which is nothing but set to `IronCore`)
+- `InstanceType`: InstanceType is set to referencing MachineClass name by the instance.
 - `NodeAddresses`: Node addresses are calculated from the IP information available from NetworkInterfaces of the machine.
-- `Zone`:  Zone is set to referenced MachinePool name.
+- `Zone`: Zone is set to referenced MachinePool name.
 
 
 ## Load balancing for Services of type LoadBalancer
@@ -47,7 +47,7 @@ explanation on how APIs are implemented in IronCore cloud-provider.
 ### Ensure LoadBalancer
 
 - `EnsureLoadBalancer` gets the LoadBalancer name based on service name.
-- Checks if IronCore `LoadBalancer` object already exists. If not it gets the `port` and `protocol`,  `ipFamily` information from the service and creates a new LoadBalancer object in the Ironcore. 
+- Checks if IronCore `LoadBalancer` object already exists. If not it gets the `port` and `protocol`, `ipFamily` information from the service and creates a new LoadBalancer object in the Ironcore. 
 - Newly created LoadBalancer will be associated with Network reference provided in cloud configuration.
 - Then `LoadBalancerRouting` object is created with the destination IP information retrieved from the nodes (Note: `LoadBalancerRouting` is internal object to Ironcore). Later, this information is used at the Ironcore API level to describe the explicit targets in a pool traffic is routed to.
 - Ironcore supports two types of LoadBalancer `Public` and `Internal`. If LoadBalancer has to be of type Internal, "service.beta.kubernetes.io/ironcore-load-balancer-internal" annotation needs to be set to true, otherwise it will be considered as public type.

docs/iaas/kubernetes/csi-driver.md

@@ -8,7 +8,7 @@ management capabilities.
 
 ## IronCore CSI Driver Integration
 
-The [Ironcore CSI Driver](https://github.com/ironcore-dev/ironcore-csi-driver) is implemented as a Kubernetes storage 
+The [IronCore CSI Driver](https://github.com/ironcore-dev/ironcore-csi-driver) is implemented as a Kubernetes storage 
 plugin that bridges the gap between Kubernetes storage management and IronCore's `storage` resource types. 
 
 The core components of the IronCore CSI driver include:
@@ -20,8 +20,8 @@ The core components of the IronCore CSI driver include:
 
 The CSI driver supports various storage class parameters for customizing volume provisioning:
 
-- **Volume Type**: Specifies the type of volume to be created (e.g., standard, high-performance)
-- **AllowVolumeExpansion**: This Specifies the Volume can be resized if set to `true` and the respective volume Type has `ResizePolicy` set to `ExpandOnly` 
+- **Volume Type**: Specifies the type of volume to be created (e.g., standard, high-performance).
+- **AllowVolumeExpansion**: This specifies that the `Volume` can be resized if set to `true` and the respective volume Type has `ResizePolicy` set to `ExpandOnly`. 
 
 ### Volume Management