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,34 @@
+default_stages: [commit]
+default_install_hook_types: [pre-commit, prepare-commit-msg]
+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
+  - repo: https://github.com/shellcheck-py/shellcheck-py
+    rev: v0.9.0.6
+    hooks:
+      - id: shellcheck
+  - repo: https://github.com/jumanjihouse/pre-commit-hook-yamlfmt
+    rev: 0.2.3
+    hooks:
+      - id: yamlfmt
+        args: [--mapping=2, --sequence=4, --offset=2, --implicit_start, --preserve-quotes]
+  - repo: https://github.com/crate-ci/typos
+    rev: v1.18.0
+    hooks:
+      - id: typos
+        exclude_types:
+          - svg

.typos.toml

@@ -0,0 +1,2 @@
+[default.extend-identifiers]
+CLOS = "CLOS"

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
@@ -26,20 +26,20 @@ simple and is ideal for very small deployments.
 
 ### Spine - Leaf
 
-A spine-leaf topology is a standard clos network with workloads attaching to leaf switches and spines providing
+A spine-leaf topology is a standard close network with workloads attaching to leaf switches and spines providing
 connectivity between different leaves.
 
 ![image](./fabric-spineleaf.png)
 
-This kind of topology is useful for bigger deployments and provides all the advantages of a typical clos network.
+This kind of topology is useful for bigger deployments and provides all the advantages of a typical close network.
 The underlay network is established using eBGP where each leaf has a separate ASN and peers will all spines in the
 network. We used [RFC7938](https://datatracker.ietf.org/doc/html/rfc7938) as the reference for establishing the
 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
@@ -58,14 +58,14 @@ implemented on the network to provice the view of a private network.
  - The vrf created on each switch corresponding to a VPC configures a BGP instance with evpn to advertise its locally
    attached subnets and import routes from its peered VPC's. The BGP instance in the tenant vrf's does not establish
    neighbor relationships and is purely used to advertise locally attached routes into the VPC (all vrf's with the same
-   l3vni) across leafs in the network.
+   l3vni) across leaves in the 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,8 +40,8 @@ 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
-    * __VPCPeering__: enables VPC to VPC connectivity (could be Local where VPCs are used or Remote peering on the border/mixed leafs)
+    * __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 leaves)
 * External API
     * __External__: definition of the "external system" to peer with (could be one or multiple devices such as edge/provider routers)
     * __ExternalAttachment__: configuration for a specific switch (using Connection object) describing how it connects to an external system
@@ -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/build-wiring.md

@@ -25,10 +25,10 @@ OPTIONS:
    --chain-control-link         chain control links instead of all switches directly connected to control node if fabric mode is spine-leaf (default: false)
    --control-links-count value  number of control links if chain-control-link is enabled (default: 0)
    --fabric-links-count value   number of fabric links if fabric mode is spine-leaf (default: 0)
-   --mclag-leafs-count value    number of mclag leafs (should be even) (default: 0)
+   --mclag-leaves-count value    number of mclag leaves (should be even) (default: 0)
    --mclag-peer-links value     number of mclag peer links for each mclag leaf (default: 0)
    --mclag-session-links value  number of mclag session links for each mclag leaf (default: 0)
-   --orphan-leafs-count value   number of orphan leafs (default: 0)
+   --orphan-leaves-count value   number of orphan leaves (default: 0)
    --spines-count value         number of spines if fabric mode is spine-leaf (default: 0)
    --vpc-loopbacks value        number of vpc loopbacks for each switch (default: 0)
 ```

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