run some pre-commit checks

.github/workflows/ci.yaml

@@ -3,8 +3,8 @@ name: Build docs
 on:
   push:
     branches:
-        - master
-        - release/*
+      - master
+      - release/*
   pull_request:
   workflow_dispatch:
     inputs:
@@ -24,8 +24,8 @@ jobs:
     steps:
       - uses: actions/checkout@v4
         with:
-            persist-credentials: false
-            fetch-depth: 0
+          persist-credentials: false
+          fetch-depth: 0
 
       - name: Build docs
         run: make build
@@ -50,10 +50,10 @@ jobs:
         # TODO support publishing non-dev versions
         if: github.event_name == 'push' && github.ref == 'refs/heads/master'
         env:
-            PUSH_TOKEN: ${{ secrets.GH_DEPLOY_PUSH_TOKEN }}
+          PUSH_TOKEN: ${{ secrets.GH_DEPLOY_PUSH_TOKEN }}
         run: |
-            make deploy RELEASE=dev ALIAS=master
-            git push https://[email protected]/${{ github.repository }} publish
+          make deploy RELEASE=dev ALIAS=master
+          git push https://[email protected]/${{ github.repository }} publish
 
       - name: Setup tmate session for debug
         if: ${{ failure() && github.event_name == 'workflow_dispatch' && inputs.debug_enabled }}

.github/workflows/publish.yaml

@@ -3,7 +3,7 @@ name: Publish docs
 on:
   push:
     branches:
-        - publish
+      - publish
   workflow_dispatch:
     inputs:
       debug_enabled:
@@ -42,4 +42,4 @@ jobs:
         uses: mxschmitt/action-tmate@v3
         timeout-minutes: 45
         with:
-          limit-access-to-actor: true
+          limit-access-to-actor: true

.pre-commit-config.yaml

@@ -0,0 +1,38 @@
+default_stages: [commit]
+default_install_hook_types: [pre-commit, prepare-commit-msg]
+exclude: |
+  (?x)^(
+    ^docs/reference/api.md
+  )
+repos:
+  - repo: https://github.com/pre-commit/pre-commit-hooks
+    rev: v4.5.0
+    hooks:
+      - id: end-of-file-fixer
+      - id: mixed-line-ending
+        args: [--fix=lf]
+      - id: trailing-whitespace
+  - repo: https://github.com/pre-commit/pygrep-hooks
+    rev: v1.10.0
+    hooks:
+      - id: text-unicode-replacement-char
+  - repo: https://github.com/scop/pre-commit-shfmt
+    rev: v3.7.0-4
+    hooks:
+      - id: shfmt-docker
+        alias: shfmt
+        args: ["-i", "2"]
+  - repo: https://github.com/shellcheck-py/shellcheck-py
+    rev: v0.9.0.6
+    hooks:
+      - id: shellcheck
+  - repo: https://github.com/google/yamlfmt
+    rev: v0.10.0
+    hooks:
+      - id: yamlfmt
+  - repo: https://github.com/crate-ci/typos
+    rev: v1.18.0
+    hooks:
+      - id: typos
+        exclude_types:
+          - svg

.typos.toml

@@ -0,0 +1,3 @@
+[default.extend-words]
+CLOS = "CLOS"
+leafs = "leafs"

.yamlfmt

@@ -0,0 +1,6 @@
+formatter:
+  type: basic
+  drop_merge_tag: true
+  pad_line_comments: 2 # Align with yamllint
+  scan_folded_as_literal: true
+  retain_line_breaks: true

Makefile

@@ -52,4 +52,4 @@ ALIAS ?= master
 deploy: docker ## Deploy documentation version with mike.
 	$(RUN) mike deploy -b publish -u $(RELEASE) $(ALIAS)
 
-# TODO we need to "deploy dev" in master and "deploy -u alpha-x latest" in release/alpha-x branches
+# TODO we need to "deploy dev" in master and "deploy -u alpha-x latest" in release/alpha-x branches

README.md

@@ -2,4 +2,4 @@
 
 [![Netlify Status](https://api.netlify.com/api/v1/badges/76ba2fb4-b33a-4f0f-b81d-c61e3b603bc9/deploy-status)](https://app.netlify.com/sites/hedgehog-docs/deploys)
 
-Published to [https://docs.githedgehog.com](https://docs.githedgehog.com).
+Published to [https://docs.githedgehog.com](https://docs.githedgehog.com).

docs/architecture/fabric.md

@@ -1,7 +1,7 @@
 # Hedgehog Network Fabric
 
 The Hedgehog Open Network Fabric is an open source network architecture that provides connectivity between virtual and
-physical workloads and provides a way to achieve network isolation between different groups of workloads using standar
+physical workloads and provides a way to achieve network isolation between different groups of workloads using standard
 BGP EVPN and vxlan technology. The fabric provides a standard kubernetes interfaces to manage the elements in the
 physical network and provides a mechanism to configure virtual networks and define attachments to these virtual networks.
 The Hedgehog Fabric provides isolation between different groups of workloads by placing them in different virtual
@@ -39,7 +39,7 @@ underlay network.
 ## Overlay Network
 
 The overlay network runs on top the underlay network to create a virtual network. The overlay network isolates control
-and data plane traffic between different virtual networks and the underlay network. Vitualization is achieved in the
+and data plane traffic between different virtual networks and the underlay network. Visualization is achieved in the
 hedgehog fabric by encapsulating workload traffic over vxlan tunnels that are source and terminated on the leaf switches
 in the network. The fabric using BGP-EVPN/Vxlan to enable creation and management of virtual networks on top of the
 virtual. The fabric supports multiple virtual networks over the same underlay network to support multi-tenancy. Each
@@ -48,7 +48,7 @@ a high level overview of how are vpc's implemented in the hedgehog fabric and it
 
 ## VPC
 We know what is a VPC and how to attach workloads to a specific VPC. Let us now take a look at how is this actually
-implemented on the network to provice the view of a private network.
+implemented on the network to provide the view of a private network.
 
  - Each VPC is modeled as a vrf on each switch where there are VPC attachments defined for this vpc.
    The Vrf is allocated its own VNI. The Vrf is local to each switch and the VNI is global for the entire fabric. By
@@ -62,10 +62,10 @@ implemented on the network to provice the view of a private network.
  - A VPC can have multuple subnets. Each Subnet in the VPC is modeled as a Vlan on the switch. The vlan is only locally
    significant and a given subnet might have different Vlan's on different leaves on the network. We assign a globally
    significant vni for each subnet. This VNI is used to extend the subnet across different leaves in the network and
-   provides a view of single streched l2 domain if the applications need it.
+   provides a view of single stretched l2 domain if the applications need it.
  - The hedgehog fabric has a built-in DHCP server which will automatically assign IP addresses to each workload
    depending on the VPC it belongs to. This is achieved by configuring a DHCP relay on each of the server facing vlans.
-   The DHCP server is accesible through the underlay network and is shared by all vpcs in the fabric. The inbuilt DHCP
+   The DHCP server is accessible through the underlay network and is shared by all vpcs in the fabric. The inbuilt DHCP
    server is capable of identifying the source VPC of the request and assigning IP addresses from a pool allocated to the
    VPC at creation.
  - A VPC by default cannot communicate to anyone outside the VPC and we need to define specific peering rules to allow
@@ -76,7 +76,7 @@ To enable communication between 2 different VPC's we need to configure a VPC pee
 supports two different peering modes.
 
 - Local Peering - A local peering directly imports routers from the other VPC locally. This is achieved by a simple
-  import route from the peer VPC. In case there are no locally attached worloads to the peer VPC the fabric
+  import route from the peer VPC. In case there are no locally attached workloads to the peer VPC the fabric
   automatically creates a stub vpc for peering and imports routes from it. This allows VPC's to peer with each other
   without the need for dedicated peering leaf. If a local peering is done for a pair of VPC's which have locally
   attached workloads the fabric automatically allocates a pair of ports on the switch to router traffic between these
@@ -88,5 +88,5 @@ supports two different peering modes.
   configuration in the peering policy. When a remote peering policy is applied for a pair of VPC's the vrf's
   corresponding to these VPC's on the peering switch advertise default routes into their specific vrf's identified
   by the l3vni. All traffic that does not belong to the VPC's is forwarded to the peering switch and which has routes
-  to the other VPC's and gets forwarded from there. The bandwith limitation that exists in the local peering solution
-  is solved here as the bandwith between the two VPC's is determined by the fabric cross section bandwidth.
+  to the other VPC's and gets forwarded from there. The bandwidth limitation that exists in the local peering solution
+  is solved here as the bandwidth between the two VPC's is determined by the fabric cross section bandwidth.

docs/architecture/overview.md

@@ -1,4 +1,4 @@
 # Overview
 
 !!! warning ""
-    Under construction.
+    Under construction.

docs/concepts/overview.md

@@ -8,7 +8,7 @@ and so you can use standard Kubernetes tools to manage Fabric resources.
 
 Hedgehog Fabric consists of the following components:
 
-* Fabricator - special tool that allows to install and configre Fabric as well as run virtual labs
+* Fabricator - special tool that allows to install and configure Fabric as well as run virtual labs
 * Control Node - one or more Kubernetes nodes in a single clusters running Fabric software
     * Das Boot - set of services providing switch boot and installation
     * Fabric Controller - main control plane component that manages Fabric resources
@@ -40,7 +40,7 @@ Wiring Diagram consists of the following resources:
 * VPC API
     * __VPC__: Virtual Private Cloud, similar to the public cloud VPC it provides an isolated private network for the
       resources with support for multiple subnets each with user-provided VLANs and on-demand DHCP
-    * __VPCAttachment__: represents a specific VPC subnet assignemnt to the Connection object which means exact server port to a VPC binding
+    * __VPCAttachment__: represents a specific VPC subnet assignment to the Connection object which means exact server port to a VPC binding
     * __VPCPeering__: enables VPC to VPC connectivity (could be Local where VPCs are used or Remote peering on the border/mixed leafs)
 * External API
     * __External__: definition of the "external system" to peer with (could be one or multiple devices such as edge/provider routers)
@@ -70,12 +70,12 @@ Installer builder and VLAB.
 Switch boot and installation.
 
 * Seeder
-  * Actual switch provisioing
+  * Actual switch provisioning
   * ONIE on a switch discovers control node using LLDP
   * It loads and runs our multi-stage installer
     * Network configuration & identity setup
     * Performs device registration
-    * Hedgehog identity partion gets created on the switch
+    * Hedgehog identity partition gets created on the switch
     * Downloads SONiC installer and runs it
     * Downloads Agent and it's config and installs to the switch
 * Registration Controller
@@ -91,7 +91,7 @@ Control plane and switch agent.
   * It includes controllers for different CRDs and needs
   * For example, auto assigning VNIs to VPC or generating Agent config
   * Additionally, it's running admission webhook for our CRD APIs
-* Agent is watching for the corresonding Agent CRD in K8s API
+* Agent is watching for the corresponding Agent CRD in K8s API
   * It applies the changes and saves new config locally
   * It reports back some status and information back to API
-  * Can perform reinstall and reboot of SONiC
+  * Can perform reinstall and reboot of SONiC

docs/contribute/docs.md

@@ -10,7 +10,7 @@ In order to contribute to the documentation, you'll need to have Git and Docker
 make serve
 ```
 
-Now you can open continuosly updated preview of your edits in browser at [http://127.0.0.1:8000](http://127.0.0.1:8000). Pages will be automatically updated while you're editing.
+Now you can open continuously updated preview of your edits in browser at [http://127.0.0.1:8000](http://127.0.0.1:8000). Pages will be automatically updated while you're editing.
 
 Additionally you can run
 
@@ -124,7 +124,7 @@ Admonitions, also known as call-outs, are an excellent choice for including side
 
 Details can be found [here](https://squidfunk.github.io/mkdocs-material/reference/code-blocks/).
 
-Simple code block with line nums and higlighted lines:
+Simple code block with line nums and highlighted lines:
 
 ```py title="bubble_sort.py" hl_lines="2 3" linenums="1"
 def bubble_sort(items):

docs/contribute/overview.md

@@ -1,4 +1,4 @@
 # Overview
 
 !!! warning ""
-    Under construction.
+    Under construction.

docs/getting-started/download.md

@@ -46,4 +46,4 @@ Currently only Linux x86 is supported for running `hhfab`.
 * [Concepts](../concepts/overview.md)
 * [Virtual LAB](../vlab/overview.md)
 * [Installation](../install-upgrade/overview.md)
-* [User guide](../user-guide/overview.md)
+* [User guide](../user-guide/overview.md)

docs/index.md

@@ -11,4 +11,4 @@ You can read more about [concepts](concepts/overview.md) and [architecture](arch
 documentation.
 
 You can find how to [download](getting-started/download.md) and try Fabric on the self-hosted
-[fully virtualized lab](vlab/overview.md) or on the [hardware](install-upgrade/overview.md).
+[fully virtualized lab](vlab/overview.md) or on the [hardware](install-upgrade/overview.md).

docs/install-upgrade/config.md

@@ -9,4 +9,4 @@
     use of on-demand DHCP for multiple IPv4/VLAN namespaces and overlapping IP ranges as well as adds DHCP leases
     into the Fabric API
 
-You can find more information about using `hhfab init` in the help message by running it with `--help` flag.
+You can find more information about using `hhfab init` in the help message by running it with `--help` flag.

docs/install-upgrade/overview.md

@@ -34,9 +34,9 @@ Main steps to install Fabric are:
 
 It's the only step that requires internet access to download artifacts and build installer.
 
-Once you've prepated Wiring Diagram, you can initialize Fabricator by running `hhfab init` command and passwing optional
+Once you've prepared Wiring Diagram, you can initialize Fabricator by running `hhfab init` command and passwing optional
 configuration into it as well as wiring diagram file(s) as flags. Additionally, there are a lot of customizations
-availble as flags, e.g. to setup default credentials, keys and etc, please, refer to `hhfab init --help` for more.
+available as flags, e.g. to setup default credentials, keys and etc, please, refer to `hhfab init --help` for more.
 
 The `--dev` options allows to enable development mode which will enable default credentials and keys for the Control
 Node and switches:
@@ -104,4 +104,4 @@ At that point, you can start interacting with the Fabric using `kubectl`, `kubec
 part of the Control Node installer.
 
 You can now get HONiE installed on your switches and reboot them into ONiE Install Mode and they will be automatically
-provisioned from the Control Node.
+provisioned from the Control Node.

docs/install-upgrade/requirements.md

@@ -1,14 +1,14 @@
 # System Requirements
 
-- Fast SSDs for system/root and K8s & container runtime forlders are required for stable work
+- Fast SSDs for system/root and K8s & container runtime folders are required for stable work
 - SSDs are mandatory for Control Nodes
-- Minimal (non-HA) setup is a single Contol Node
+- Minimal (non-HA) setup is a single Control Node
 - (Future) Full (HA) setup is at least 3 Control Nodes
 - (Future) Extra nodes could be used for things like Logging, Monitoring, Alerting stack and etc.
 
 ## Non-HA (minimal) setup - 1 Control Node
 
-- Control Node runs non-HA K8s Contol Plane installation with non-HA Hedgehog Fabric Control Plane on top of it
+- Control Node runs non-HA K8s Control Plane installation with non-HA Hedgehog Fabric Control Plane on top of it
 - Not recommended for more then 10 devices participating in the Hedgehog Fabric or production deployments
 
 |      | Minimal | Recommended |
@@ -19,7 +19,7 @@
 
 ## (Future) HA setup - 3+ Control Nodes (per node)
 
-- Each Contol Node runs part of the HA K8s Control Plane installation with Hedgehog Fabric Control Plane on top of it in
+- Each Control Node runs part of the HA K8s Control Plane installation with Hedgehog Fabric Control Plane on top of it in
   HA mode as well
 - Recommended for all cases where more then 10 devices participating in the Hedgehog Fabric
 

docs/reference/cli.md

@@ -54,4 +54,4 @@ To peer VPC with another VPC (e.g. `vpc-2`) use the following command:
 
 ```bash
 core@control-1 ~ $ kubectl fabric vpc peer --vpc vpc-1 --vpc vpc-2
-```
+```

docs/troubleshooting/overview.md

@@ -1,4 +1,4 @@
 # Troubleshooting
 
 !!! warning ""
-    Under construction.
+    Under construction.

docs/user-guide/connections.md

@@ -256,4 +256,4 @@ spec:
     link: # Defines a single link between a switch and an external system
       switch:
         port: s5248-03/Ethernet3
-```
+```

docs/user-guide/devices.md

@@ -76,4 +76,4 @@ metadata:
   namespace: default
 spec:
   description: MH s5248-01/E1 s5248-02/E1
-```
+```

docs/user-guide/external.md

@@ -278,4 +278,4 @@ route-map HedgeOut permit 10
 !
 
 bgp community-list standard HedgeIn permit 5000:65102
-```
+```

docs/user-guide/harvester.md

@@ -9,7 +9,7 @@ connection to the switches.
 You can have multiple VPCs created and attached to the `Connections` to this servers to make them available to the VMs
 in Harvester or any other hypervisor.
 
-## Congigure Harvester
+## Configure Harvester
 
 ### Add a Cluster Network
 

docs/user-guide/overview.md

@@ -1,3 +1,3 @@
 # Overview
 
-The chapter is intended to give an overview of the main features of the Hedgehog Fabric and their usage.
+The chapter is intended to give an overview of the main features of the Hedgehog Fabric and their usage.

docs/user-guide/vpcs.md

@@ -42,7 +42,7 @@ information is added under the RelayAgentInfo option(82) on the DHCP packet. The
 
 ## VPCAttachment
 
-Represents a specific VPC subnet assignemnt to the `Connection` object which means exact server port to a VPC binding.
+Represents a specific VPC subnet assignment to the `Connection` object which means exact server port to a VPC binding.
 It basically leads to the VPC being available on the specific server port(s) on a subnet VLAN.
 
 VPC could be attached to a switch which is a part of the VLAN namespace used by the VPC.
@@ -126,4 +126,4 @@ spec:
   ranges: # List of VLAN ranges that VPCs can pick their subnet VLANs from
   - from: 1000
     to: 2999
-```
+```

docs/vlab/running.md

@@ -172,7 +172,7 @@ node and other VMs to watch the Fabric coming up and switches getting provisione
 By default, all test server VMs are isolated and have no connectivity to the host or internet. You can configure it
 using `hhfab vlab up --restrict-servers=false` flag to allow the test servers to access the internet and the host. It
 will mean that VMs will have default route pointing to the host which means in case of the VPC peering you'll need to
-configure test server VMs to use the VPC attachement as a default route (or just some specific subnets).
+configure test server VMs to use the VPC attachment as a default route (or just some specific subnets).
 
 Additionally, you can configure the size of all VMs using `hhfab vlab up --vm-size <size>` flag. It will allow you to
 choose from one of the presets (compact, default, full and huge) to get the control, switch and server VMs of different

hhdocs/Dockerfile

@@ -7,4 +7,3 @@ COPY gitconfig /root/.gitconfig
 
 COPY entrypoint.sh /entrypoint.sh
 ENTRYPOINT ["/entrypoint.sh"]
-