From 7a3b475ac600cbcbcdcaad223c3c644023fb6498 Mon Sep 17 00:00:00 2001 From: Florian Berchtold Date: Sun, 4 Feb 2024 20:08:05 -0800 Subject: [PATCH] run some pre-commit checks --- .github/workflows/ci.yaml | 14 ++++++------ .github/workflows/publish.yaml | 4 ++-- .pre-commit-config.yaml | 34 ++++++++++++++++++++++++++++ .typos.toml | 2 ++ Makefile | 2 +- README.md | 2 +- docs/architecture/fabric.md | 22 +++++++++--------- docs/architecture/overview.md | 2 +- docs/concepts/overview.md | 14 ++++++------ docs/contribute/docs.md | 4 ++-- docs/contribute/overview.md | 2 +- docs/getting-started/download.md | 2 +- docs/index.md | 2 +- docs/install-upgrade/build-wiring.md | 4 ++-- docs/install-upgrade/config.md | 2 +- docs/install-upgrade/overview.md | 6 ++--- docs/install-upgrade/requirements.md | 8 +++---- docs/reference/api.md | 17 ++++++-------- docs/reference/cli.md | 2 +- docs/troubleshooting/overview.md | 2 +- docs/user-guide/connections.md | 2 +- docs/user-guide/devices.md | 2 +- docs/user-guide/external.md | 6 ++--- docs/user-guide/harvester.md | 2 +- docs/user-guide/overview.md | 2 +- docs/user-guide/vpcs.md | 6 ++--- docs/vlab/demo.md | 2 +- docs/vlab/overview.md | 2 +- docs/vlab/running.md | 18 +++++++-------- hhdocs/Dockerfile | 3 +-- hhdocs/entrypoint.sh | 12 +++++----- hhdocs/gitconfig | 2 +- hhdocs/requirements.txt | 2 +- includes/abbreviations.md | 4 ++-- mkdocs.yml | 6 ++--- overrides/main.html | 2 +- 36 files changed, 126 insertions(+), 94 deletions(-) create mode 100644 .pre-commit-config.yaml create mode 100644 .typos.toml diff --git a/.github/workflows/ci.yaml b/.github/workflows/ci.yaml index 1f495ee..ac5c447 100644 --- a/.github/workflows/ci.yaml +++ b/.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://$PUSH_TOKEN@github.com/${{ github.repository }} publish + make deploy RELEASE=dev ALIAS=master + git push https://$PUSH_TOKEN@github.com/${{ github.repository }} publish - name: Setup tmate session for debug if: ${{ failure() && github.event_name == 'workflow_dispatch' && inputs.debug_enabled }} diff --git a/.github/workflows/publish.yaml b/.github/workflows/publish.yaml index fbcbd92..b62bc5f 100644 --- a/.github/workflows/publish.yaml +++ b/.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 \ No newline at end of file + limit-access-to-actor: true diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml new file mode 100644 index 0000000..942c2fc --- /dev/null +++ b/.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 diff --git a/.typos.toml b/.typos.toml new file mode 100644 index 0000000..aad38b8 --- /dev/null +++ b/.typos.toml @@ -0,0 +1,2 @@ +[default.extend-identifiers] +CLOS = "CLOS" diff --git a/Makefile b/Makefile index eb33d04..a5b074e 100644 --- a/Makefile +++ b/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 \ No newline at end of file +# TODO we need to "deploy dev" in master and "deploy -u alpha-x latest" in release/alpha-x branches diff --git a/README.md b/README.md index 15050fd..3fe05ce 100644 --- a/README.md +++ b/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). \ No newline at end of file +Published to [https://docs.githedgehog.com](https://docs.githedgehog.com). diff --git a/docs/architecture/fabric.md b/docs/architecture/fabric.md index 7675727..66083aa 100644 --- a/docs/architecture/fabric.md +++ b/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,12 +26,12 @@ 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. @@ -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 @@ -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. diff --git a/docs/architecture/overview.md b/docs/architecture/overview.md index aad7629..8c39248 100644 --- a/docs/architecture/overview.md +++ b/docs/architecture/overview.md @@ -1,4 +1,4 @@ # Overview !!! warning "" - Under construction. \ No newline at end of file + Under construction. diff --git a/docs/concepts/overview.md b/docs/concepts/overview.md index 991bee9..10ce176 100644 --- a/docs/concepts/overview.md +++ b/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 \ No newline at end of file + * Can perform reinstall and reboot of SONiC diff --git a/docs/contribute/docs.md b/docs/contribute/docs.md index cf5edce..6c0d8f9 100644 --- a/docs/contribute/docs.md +++ b/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): diff --git a/docs/contribute/overview.md b/docs/contribute/overview.md index aad7629..8c39248 100644 --- a/docs/contribute/overview.md +++ b/docs/contribute/overview.md @@ -1,4 +1,4 @@ # Overview !!! warning "" - Under construction. \ No newline at end of file + Under construction. diff --git a/docs/getting-started/download.md b/docs/getting-started/download.md index b48feda..457cf4d 100644 --- a/docs/getting-started/download.md +++ b/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) \ No newline at end of file +* [User guide](../user-guide/overview.md) diff --git a/docs/index.md b/docs/index.md index 6691cda..6b1e228 100644 --- a/docs/index.md +++ b/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). \ No newline at end of file +[fully virtualized lab](vlab/overview.md) or on the [hardware](install-upgrade/overview.md). diff --git a/docs/install-upgrade/build-wiring.md b/docs/install-upgrade/build-wiring.md index 7416d5b..f9117fb 100644 --- a/docs/install-upgrade/build-wiring.md +++ b/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) ``` diff --git a/docs/install-upgrade/config.md b/docs/install-upgrade/config.md index c35c02d..c7d5d1c 100644 --- a/docs/install-upgrade/config.md +++ b/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. \ No newline at end of file +You can find more information about using `hhfab init` in the help message by running it with `--help` flag. diff --git a/docs/install-upgrade/overview.md b/docs/install-upgrade/overview.md index 9dcb316..176a185 100644 --- a/docs/install-upgrade/overview.md +++ b/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. \ No newline at end of file +provisioned from the Control Node. diff --git a/docs/install-upgrade/requirements.md b/docs/install-upgrade/requirements.md index 28a9ab8..a9b287b 100644 --- a/docs/install-upgrade/requirements.md +++ b/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 diff --git a/docs/reference/api.md b/docs/reference/api.md index abdd110..57b3e13 100644 --- a/docs/reference/api.md +++ b/docs/reference/api.md @@ -90,7 +90,7 @@ _Appears in:_ ## dhcp.githedgehog.com/v1alpha2 -Package v1alpha2 contains API Schema definitions for the dhcp v1alpha2 API group. It is the primarely internal API +Package v1alpha2 contains API Schema definitions for the dhcp v1alpha2 API group. It is the primarily internal API group for the intended Hedgehog DHCP server configuration and storing leases as well as making them available to the end user through API. Not intended to be modified by the user. @@ -119,7 +119,7 @@ _Appears in:_ -DHCPSubnet is the configuration (spec) for the Hedgehog DHCP server and storage for the leases (status). It's primarely internal API group, but it makes allocated IPs / leases information available to the end user through API. Not intended to be modified by the user. +DHCPSubnet is the configuration (spec) for the Hedgehog DHCP server and storage for the leases (status). It's primarily internal API group, but it makes allocated IPs / leases information available to the end user through API. Not intended to be modified by the user. @@ -149,7 +149,7 @@ _Appears in:_ | `startIP` _string_ | Start IP from the CIDRBlock to allocate IPs, such as 10.10.10.10 | | `endIP` _string_ | End IP from the CIDRBlock to allocate IPs, such as 10.10.10.99 | | `vrf` _string_ | VRF name to identify specific VPC (will be added to DHCP packets by DHCP relay in suboption 151), such as "VrfVvpc-1" as it's named on switch | -| `circuitID` _string_ | VLAN ID to identify specific subnet withing the VPC, such as "Vlan1000" as it's named on switch | +| `circuitID` _string_ | VLAN ID to identify specific subnet within the VPC, such as "Vlan1000" as it's named on switch | #### DHCPSubnetStatus @@ -245,7 +245,7 @@ _Appears in:_ | Field | Description | | --- | --- | | `external` _string_ | External is the name of the External object this attachment belongs to | -| `connection` _string_ | Connection is the name of the Connection object this attachment belongs to (essentialy the name of the switch/port) | +| `connection` _string_ | Connection is the name of the Connection object this attachment belongs to (essentially the name of the switch/port) | | `switch` _[ExternalAttachmentSwitch](#externalattachmentswitch)_ | Switch is the switch port configuration for the external attachment | | `neighbor` _[ExternalAttachmentNeighbor](#externalattachmentneighbor)_ | Neighbor is the BGP neighbor configuration for the external attachment | @@ -412,7 +412,7 @@ _Appears in:_ -IPv4Namespace represents a namespace for VPC subnets allocation. All VPC subnets withing a single IPv4Namespace are non-overlapping. Users can create multiple IPv4Namespaces to allocate same VPC subnets. +IPv4Namespace represents a namespace for VPC subnets allocation. All VPC subnets within a single IPv4Namespace are non-overlapping. Users can create multiple IPv4Namespaces to allocate same VPC subnets. @@ -557,7 +557,7 @@ _Appears in:_ -VPCPeering represents a peering between two VPCs with corresponding filtering rules. Minimal example of the VPC peering showing vpc-1 to vpc-2 peering with all subnets allowed: +VPCPeering represents a peering between two VPCs with corresponding filtering rules. Minimal example of the VPC peering showing vpc-1 to vpc-2 peering with all subnets allowed: spec: permit: - vpc-1: {} vpc-2: {} @@ -1197,7 +1197,7 @@ _Appears in:_ -Switch is the Schema for the switches API +Switch is the Schema for the switches API All switches should always have 1 labels defined: wiring.githedgehog.com/rack. It represents name of the rack it belongs to. @@ -1373,6 +1373,3 @@ VLANNamespaceStatus defines the observed state of VLANNamespace _Appears in:_ - [VLANNamespace](#vlannamespace) - - - diff --git a/docs/reference/cli.md b/docs/reference/cli.md index 1980257..d4aafe7 100644 --- a/docs/reference/cli.md +++ b/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 -``` \ No newline at end of file +``` diff --git a/docs/troubleshooting/overview.md b/docs/troubleshooting/overview.md index b703ae5..183e4ea 100644 --- a/docs/troubleshooting/overview.md +++ b/docs/troubleshooting/overview.md @@ -1,4 +1,4 @@ # Troubleshooting !!! warning "" - Under construction. \ No newline at end of file + Under construction. diff --git a/docs/user-guide/connections.md b/docs/user-guide/connections.md index 72b3678..5d557a4 100644 --- a/docs/user-guide/connections.md +++ b/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 -``` \ No newline at end of file +``` diff --git a/docs/user-guide/devices.md b/docs/user-guide/devices.md index e875499..fb53c9e 100644 --- a/docs/user-guide/devices.md +++ b/docs/user-guide/devices.md @@ -76,4 +76,4 @@ metadata: namespace: default spec: description: MH s5248-01/E1 s5248-02/E1 -``` \ No newline at end of file +``` diff --git a/docs/user-guide/external.md b/docs/user-guide/external.md index 12a7948..a6d9295 100644 --- a/docs/user-guide/external.md +++ b/docs/user-guide/external.md @@ -8,9 +8,9 @@ internal and external endpoints. ## Overview -Traffic exit from the Fabric is done on Border Leafs that are connected with Edge devices. Border Leafs are suitable to +Traffic exit from the Fabric is done on Border Leaves that are connected with Edge devices. Border Leaves are suitable to terminate l2vpn connections and distinguish VPC L3 routable traffic towards Edge device as well as to land VPC servers. -Border Leafs (or Borders) can connect to several Edge devices. +Border Leaves (or Borders) can connect to several Edge devices. >External Peering is only available on the switch devices that are capable for sub-interfaces. @@ -278,4 +278,4 @@ route-map HedgeOut permit 10 ! bgp community-list standard HedgeIn permit 5000:65102 -``` \ No newline at end of file +``` diff --git a/docs/user-guide/harvester.md b/docs/user-guide/harvester.md index e3164cf..f0a9346 100644 --- a/docs/user-guide/harvester.md +++ b/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 diff --git a/docs/user-guide/overview.md b/docs/user-guide/overview.md index 8188b2c..3ee44b2 100644 --- a/docs/user-guide/overview.md +++ b/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. \ No newline at end of file +The chapter is intended to give an overview of the main features of the Hedgehog Fabric and their usage. diff --git a/docs/user-guide/vpcs.md b/docs/user-guide/vpcs.md index 246c790..4c3d170 100644 --- a/docs/user-guide/vpcs.md +++ b/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. @@ -63,7 +63,7 @@ spec: It enables VPC to VPC connectivity. There are tw o types of VPC peering: * Local - peering is implemented on the same switches where VPCs are attached -* Remote - peering is implemented on the border/mixed leafs defined by the `SwitchGroup` object +* Remote - peering is implemented on the border/mixed leaves defined by the `SwitchGroup` object VPC peering is only possible between VPCs attached to the same IPv4 namespace. @@ -126,4 +126,4 @@ spec: ranges: # List of VLAN ranges that VPCs can pick their subnet VLANs from - from: 1000 to: 2999 -``` \ No newline at end of file +``` diff --git a/docs/vlab/demo.md b/docs/vlab/demo.md index 04af690..1db9a67 100644 --- a/docs/vlab/demo.md +++ b/docs/vlab/demo.md @@ -7,7 +7,7 @@ You can find instructions on how to setup VLAB in the [Overview](overview.md) an ## Default topology -The default topology is Spine-Leaf with 2 spines, 2 MCLAG leafs and 1 non-MCLAG leaf. +The default topology is Spine-Leaf with 2 spines, 2 MCLAG leaves and 1 non-MCLAG leaf. Optionally, you can choose to run default Collapsed Core topology using `--fabric-mode collapsed-core` (or `-m collapsed-core`) flag which only conisists of 2 switches. diff --git a/docs/vlab/overview.md b/docs/vlab/overview.md index 01fdf12..aff1282 100644 --- a/docs/vlab/overview.md +++ b/docs/vlab/overview.md @@ -23,7 +23,7 @@ up-to-date packages. Following packages needs to be installed: `qemu-kvm swtpm-tools tpm2-tools socat` and docker will be required to login into OCI registry. -By default, VLAB topology is Spine-Leaf with 2 spines, 2 MCLAG leafs and 1 non-MCLAG leaf. Optionally, you can choose +By default, VLAB topology is Spine-Leaf with 2 spines, 2 MCLAG leaves and 1 non-MCLAG leaf. Optionally, you can choose to run default Collapsed Core topology using `--fabric-mode collapsed-core` (or `-m collapsed-core`) flag which only conisists of 2 switches. diff --git a/docs/vlab/running.md b/docs/vlab/running.md index f3f0340..9ce6b42 100644 --- a/docs/vlab/running.md +++ b/docs/vlab/running.md @@ -8,10 +8,10 @@ before running VLAB. As a first step you need to initialize Fabricator for the VLAB by running `hhfab init --preset vlab` (or `-p vlab`). It supports a lot of customization options which you can find by adding `--help` to the command. If you want to tune the topology used for the VLAB you can use `--fabric-mode` (or `-m`) flag to choose between `spine-leaf` (default) and -`collapsed-core` topologies as well as you can configure the number of spines, leafs, connections and etc. For example, -`--spines-count` and `--mclag-leafs-count` flags allows to set number of spines and MCLAG leafs respectively. +`collapsed-core` topologies as well as you can configure the number of spines, leaves, connections and etc. For example, +`--spines-count` and `--mclag-leaves-count` flags allows to set number of spines and MCLAG leaves respectively. -So, by default you'll get 2 spines, 2 MCLAG leafs and 1 non-MCLAG leaf with 2 fabric connections (between each spine and +So, by default you'll get 2 spines, 2 MCLAG leaves and 1 non-MCLAG leaf with 2 fabric connections (between each spine and leaf), 2 MCLAG peer links and 2 MCLAG session links as well as 2 loopbacks per leaf for implementing VPC Loopback workaround. @@ -20,7 +20,7 @@ ubuntu@docs:~$ hhfab init -p vlab 01:17:44 INF Generating wiring from gen flags 01:17:44 INF Building wiring diagram fabricMode=spine-leaf chainControlLink=false controlLinksCount=0 01:17:44 INF >>> spinesCount=2 fabricLinksCount=2 -01:17:44 INF >>> mclagLeafsCount=2 orphanLeafsCount=1 +01:17:44 INF >>> mclagLeavesCount=2 orphanLeavesCount=1 01:17:44 INF >>> mclagSessionLinks=2 mclagPeerLinks=2 01:17:44 INF >>> vpcLoopbacks=2 01:17:44 WRN Wiring is not hydrated, hydrating reason="error validating wiring: ASN not set for switch leaf-01" @@ -33,21 +33,21 @@ Or if you want to run Collapsed Core topology with 2 MCLAG switches: ubuntu@docs:~$ hhfab init -p vlab -m collapsed-core 01:20:07 INF Generating wiring from gen flags 01:20:07 INF Building wiring diagram fabricMode=collapsed-core chainControlLink=false controlLinksCount=0 -01:20:07 INF >>> mclagLeafsCount=2 orphanLeafsCount=0 +01:20:07 INF >>> mclagLeavesCount=2 orphanLeavesCount=0 01:20:07 INF >>> mclagSessionLinks=2 mclagPeerLinks=2 01:20:07 INF >>> vpcLoopbacks=2 01:20:07 WRN Wiring is not hydrated, hydrating reason="error validating wiring: ASN not set for switch leaf-01" 01:20:07 INF Initialized preset=vlab fabricMode=collapsed-core config=.hhfab/config.yaml wiring=.hhfab/wiring.yaml ``` -Or you can run custom topology with 2 spines, 4 MCLAG leafs and 2 non-MCLAG leafs using flags: +Or you can run custom topology with 2 spines, 4 MCLAG leaves and 2 non-MCLAG leaves using flags: ```bash -ubuntu@docs:~$ hhfab init -p vlab --mclag-leafs-count 4 --orphan-leafs-count 2 +ubuntu@docs:~$ hhfab init -p vlab --mclag-leaves-count 4 --orphan-leaves-count 2 01:21:53 INF Generating wiring from gen flags 01:21:53 INF Building wiring diagram fabricMode=spine-leaf chainControlLink=false controlLinksCount=0 01:21:53 INF >>> spinesCount=2 fabricLinksCount=2 -01:21:53 INF >>> mclagLeafsCount=4 orphanLeafsCount=2 +01:21:53 INF >>> mclagLeavesCount=4 orphanLeavesCount=2 01:21:53 INF >>> mclagSessionLinks=2 mclagPeerLinks=2 01:21:53 INF >>> vpcLoopbacks=2 01:21:53 WRN Wiring is not hydrated, hydrating reason="error validating wiring: ASN not set for switch leaf-01" @@ -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 ` 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 diff --git a/hhdocs/Dockerfile b/hhdocs/Dockerfile index c8ab0e7..4873f02 100644 --- a/hhdocs/Dockerfile +++ b/hhdocs/Dockerfile @@ -1,4 +1,4 @@ -FROM squidfunk/mkdocs-material +FROM squidfunk/mkdocs-material:9 COPY requirements.txt /requirements.txt RUN pip install -r /requirements.txt @@ -7,4 +7,3 @@ COPY gitconfig /root/.gitconfig COPY entrypoint.sh /entrypoint.sh ENTRYPOINT ["/entrypoint.sh"] - diff --git a/hhdocs/entrypoint.sh b/hhdocs/entrypoint.sh index f626711..a6a540e 100755 --- a/hhdocs/entrypoint.sh +++ b/hhdocs/entrypoint.sh @@ -6,12 +6,12 @@ if [ "$#" -eq "0" ]; then fi if [ "$1" = "mkdocs" ]; then - shift - mkdocs "$@" + shift + mkdocs "$@" elif [ "$1" = "mike" ]; then - shift - mike "$@" + shift + mike "$@" else - echo "Only mkdocs and mike commands are available" + echo "Only mkdocs and mike commands are available" exit 1 -fi \ No newline at end of file +fi diff --git a/hhdocs/gitconfig b/hhdocs/gitconfig index 116cdb6..6ded5dd 100644 --- a/hhdocs/gitconfig +++ b/hhdocs/gitconfig @@ -4,4 +4,4 @@ [safe] directory = /docs - directory = /site \ No newline at end of file + directory = /site diff --git a/hhdocs/requirements.txt b/hhdocs/requirements.txt index c14ca13..33d8488 100644 --- a/hhdocs/requirements.txt +++ b/hhdocs/requirements.txt @@ -4,4 +4,4 @@ mkdocs-git-revision-date-localized-plugin mkdocs-redirects mkdocs-awesome-pages-plugin mkdocs-htmlproofer-plugin -mike \ No newline at end of file +mike diff --git a/includes/abbreviations.md b/includes/abbreviations.md index 93df832..70c5508 100644 --- a/includes/abbreviations.md +++ b/includes/abbreviations.md @@ -1,8 +1,8 @@ *[HTML]: Hyper Text Markup Language *[W3C]: World Wide Web Consortium *[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]: 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 *[ExternalPeering]: Enables VPC to External connectivity by exposing specific VPC subnets to the external system and allowing inbound routes from it diff --git a/mkdocs.yml b/mkdocs.yml index 73790e2..68c37fc 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -86,7 +86,7 @@ markdown_extensions: custom_fences: - name: mermaid class: mermaid - format: !!python/name:pymdownx.superfences.fence_code_format + format: !%21python/name:pymdownx.superfences.fence_code_format - pymdownx.snippets: auto_append: - includes/abbreviations.md @@ -103,8 +103,8 @@ markdown_extensions: - pymdownx.mark - pymdownx.tilde - pymdownx.emoji: - emoji_index: !!python/name:material.extensions.emoji.twemoji - emoji_generator: !!python/name:material.extensions.emoji.to_svg + emoji_index: !%21python/name:material.extensions.emoji.twemoji + emoji_generator: !%21python/name:material.extensions.emoji.to_svg watch: - includes diff --git a/overrides/main.html b/overrides/main.html index a55b6d6..232f56b 100644 --- a/overrides/main.html +++ b/overrides/main.html @@ -9,4 +9,4 @@ {% block announce %} Documentation is under construction and may be incomplete. -{% endblock %} \ No newline at end of file +{% endblock %}