From a8518877634e4de8743e015279750190ad6f65bf Mon Sep 17 00:00:00 2001 From: cannarelladev Date: Tue, 17 Oct 2023 19:33:42 +0200 Subject: [PATCH] Improve actions, linting and documentation --- .github/workflows/build.yaml | 13 -- .../workflows/check-helm-documentation.yml | 82 ++++++++++ .github/workflows/check_artifacts.yaml | 2 +- .github/workflows/lint.yaml | 125 ++++++++++++++ .golangci.yml | 154 ++++++++++++++++++ .markdownlint.yml | 5 + .markdownlintignore | 2 + README.md | 13 +- docs/implementation/components.md | 34 ++-- docs/implementation/controllers.md | 22 +-- docs/implementation/customresources.md | 31 ++-- docs/implementation/implementation.md | 5 +- docs/installation/installation.md | 1 - docs/quickstart/quickstart.md | 1 - examples/kind/README.md | 49 ++++-- examples/kind/setup.sh | 6 +- 16 files changed, 469 insertions(+), 76 deletions(-) create mode 100644 .github/workflows/check-helm-documentation.yml create mode 100644 .github/workflows/lint.yaml create mode 100644 .golangci.yml create mode 100644 .markdownlint.yml create mode 100644 .markdownlintignore diff --git a/.github/workflows/build.yaml b/.github/workflows/build.yaml index d5c5445..02e2f39 100644 --- a/.github/workflows/build.yaml +++ b/.github/workflows/build.yaml @@ -57,19 +57,6 @@ jobs: echo "repo-name=${{ github.event.client_payload.github.payload.repository.full_name }}" >> $GITHUB_OUTPUT fi - # Since we are using a repository-dispatch event, we have to explicitly set a run check. We initialize it to a "pending" state. - # - uses: octokit/request-action@v2.x - # name: "Initialize run check to 'pending (For PR-only)" - # with: - # route: POST /repos/${{ github.repository }}/statuses/${{ steps.configure.outputs.commit-ref }} - # state: "pending" - # description: "Component build status" - # context: "Components building" - # target_url: "https://github.com/${{ github.repository }}/actions/runs/${{ github.run_id }}" - # env: - # GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} - # if: ${{ github.event_name == 'repository_dispatch' }} - build: permissions: contents: write diff --git a/.github/workflows/check-helm-documentation.yml b/.github/workflows/check-helm-documentation.yml new file mode 100644 index 0000000..1b817a2 --- /dev/null +++ b/.github/workflows/check-helm-documentation.yml @@ -0,0 +1,82 @@ +name: Check Generated Helm documentation +on: + pull_request: + types: + - opened + - reopened + - synchronize + +jobs: + generated-helm-documentation: + name: Check Helm Documentation + runs-on: ubuntu-latest + steps: + - name: Checkout + uses: actions/checkout@v4 + with: + ref: "${{ github.event.pull_request.head.sha }}" + persist-credentials: false + + - name: Setup helm-docs + run: | + version=1.11.0 + arch=x86_64 + curl -LO https://github.com/norwoodj/helm-docs/releases/download/v${version}/helm-docs_${version}_linux_${arch}.tar.gz + tar -zxvf helm-docs_${version}_linux_${arch}.tar.gz + sudo mv helm-docs /usr/local + + - name: Run the automatic generation of helm-docs + working-directory: ./deployments/node + run: | + /usr/local/helm-docs -o new_README.md -t README.gotmpl + + - name: Gather the helm-docs differences + id: helm-docs-diff + working-directory: ./deployments/node + run: | + output=$(diff README.md new_README.md | head -n 100 ) + exit_code=$([ "${output}" ] && echo 1 || echo 0) + + # Required to correctly manage multi-line outputs + output="${output//'%'/'%25'}" + output="${output//$'\n'/'%0A'}" + output="${output//$'\r'/'%0D'}" + + # Store the different as step output + echo "diff=${output}" >> $GITHUB_OUTPUT + + # Trigger a failure in case the diff is not empty + exit ${exit_code} + + - name: Log the error if the diff is not empty (in case the comment cannot be generated) + run: | + echo "The Helm README.md appear to be out-of-date." + echo + echo "Here it is an excerpt of the diff:" + echo "${{ steps.helm-docs-diff.outputs.diff }}" + if: failure() + + - name: Issue a comment in case the diff is not empty + uses: peter-evans/create-or-update-comment@v3 + with: + token: ${{ secrets.CI_TOKEN }} + issue-number: ${{ github.event.pull_request.number }} + body: | + The Helm README.md appears to be out-of-date. + + Please, run + ``` + make docs + ``` + +
+ Here it is an excerpt of the diff: + + ```diff + ${{ steps.helm-docs-diff.outputs.diff }} + ``` +
+ reactions: confused + if: | + github.event_name != 'push' && failure() && + github.event.pull_request.head.repo.full_name == github.repository diff --git a/.github/workflows/check_artifacts.yaml b/.github/workflows/check_artifacts.yaml index 0d159c5..2249e2d 100644 --- a/.github/workflows/check_artifacts.yaml +++ b/.github/workflows/check_artifacts.yaml @@ -8,7 +8,7 @@ on: jobs: generated-artifacts: - name: Check Generated Artifacts + name: Check Artifacts runs-on: ubuntu-latest steps: - name: Checkout diff --git a/.github/workflows/lint.yaml b/.github/workflows/lint.yaml new file mode 100644 index 0000000..15d0fca --- /dev/null +++ b/.github/workflows/lint.yaml @@ -0,0 +1,125 @@ +name: Linting +on: + pull_request: + +jobs: + golangci: + name: Lint golang files + runs-on: ubuntu-latest + steps: + - name: Checkout + uses: actions/checkout@v4 + with: + ref: ${{ github.event.pull_request.head.sha }} + repository: ${{github.event.pull_request.head.repo.full_name}} + persist-credentials: false + + - name: Setup Go + uses: actions/setup-go@v4 + with: + go-version: "1.21" + cache: false + + - name: golangci-lint + uses: golangci/golangci-lint-action@v3.7.0 + with: + only-new-issues: true + version: v1.54.2 + args: --timeout=900s + + gomodtidy: + name: Enforce go.mod tidiness + runs-on: ubuntu-latest + + steps: + - name: Checkout + uses: actions/checkout@v4 + with: + ref: "${{ github.event.pull_request.head.sha }}" + repository: ${{github.event.pull_request.head.repo.full_name}} + persist-credentials: false + + - name: Setup Go + uses: actions/setup-go@v4 + with: + go-version: "1.21" + + - name: Execute go mod tidy and check the outcome + working-directory: ./ + run: | + go mod tidy + exit_code=$(git diff --exit-code) + exit ${exit_code} + + - name: Issue a comment in case the of failure + uses: peter-evans/create-or-update-comment@v3 + with: + token: ${{ secrets.CI_TOKEN }} + issue-number: ${{ github.event.pull_request.number }} + body: | + The `go.mod` and/or `go.sum` files appear not to be correctly tidied. + + Please, rerun `go mod tidy` to fix the issues. + reactions: confused + if: | + failure() && github.event.pull_request.head.repo.full_name == github.repository + + shelllint: + name: Lint bash files + runs-on: ubuntu-latest + steps: + - name: Checkout code + uses: actions/checkout@v4 + with: + ref: "${{ github.event.pull_request.head.sha }}" + repository: ${{github.event.pull_request.head.repo.full_name}} + persist-credentials: false + - name: Run Shellcheck + uses: ludeeus/action-shellcheck@2.0.0 + env: + # Allow 'source' outside of FILES + SHELLCHECK_OPTS: -x + + markdownlint: + name: Lint markdown files + runs-on: ubuntu-latest + steps: + - name: Check out code + uses: actions/checkout@v4 + with: + ref: "${{ github.event.pull_request.head.sha }}" + repository: ${{github.event.pull_request.head.repo.full_name}} + persist-credentials: false + - name: Lint markdown files + uses: avto-dev/markdown-lint@v1 + with: + config: ".markdownlint.yml" + args: "**/*.md" + ignore: .github/ISSUE_TEMPLATE/*.md + + doclint: + name: Lint documentation files + runs-on: ubuntu-latest + steps: + - name: Check out code + uses: actions/checkout@v4 + with: + ref: "${{ github.event.pull_request.head.sha }}" + repository: ${{github.event.pull_request.head.repo.full_name}} + persist-credentials: false + - name: Setup python3 + uses: actions/setup-python@v4 + with: + python-version: "3.x" + - name: Install python3 dependencies + working-directory: ./docs + run: | + pip3 install -r requirements.txt + - name: Build documentation + working-directory: ./docs + run: | + make dummy + - name: Check external links + working-directory: ./docs + run: | + make linkcheck diff --git a/.golangci.yml b/.golangci.yml new file mode 100644 index 0000000..dc67665 --- /dev/null +++ b/.golangci.yml @@ -0,0 +1,154 @@ +run: + timeout: 10m + skip-files: + - "zz_generated.*.go" + skip-dirs: + - "pkg/client" + +linters-settings: + exhaustive: + check-generated: false + default-signifies-exhaustive: true + + goheader: + values: + const: + AUTHORS: FLUIDOS Project + template: |- + Copyright 2019-{{ YEAR }} {{ AUTHORS }} + + Licensed under the Apache License, Version 2.0 (the "License"); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. + + lll: + line-length: 150 + gomodguard: + blocked: + modules: + - github.com/go-logr/logr: + recommendations: + - k8s.io/klog/v2 + gci: + sections: + - standard # Captures all standard packages if they do not match another section. + - default # Contains all imports that could not be matched to another section type. + - prefix(github.com/fluidos-project/node) # Groups all imports with the specified Prefix. + goconst: + min-len: 2 + min-occurrences: 2 + gocritic: + enabled-tags: + - diagnostic + - experimental + - opinionated + - performance + - style + disabled-checks: + # Conflicts with govet check-shadowing + - sloppyReassign + goimports: + local-prefixes: github.com/fluidos-project/node + govet: + check-shadowing: true + misspell: + locale: US + nolintlint: + allow-leading-space: true # don't require machine-readable nolint directives (i.e. with no leading space) + allow-unused: false # report any unused nolint directives + require-explanation: true # require an explanation for nolint directives + require-specific: true # require nolint directives to be specific about which linter is being skipped + dupl: + threshold: 300 + +linters: + disable-all: true + enable: + - asciicheck + - bodyclose + # - depguard + - dogsled + - dupl + - errcheck + - errorlint + - exhaustive + - exportloopref + # - funlen + # - gochecknoglobals + # - gochecknoinits + # - gocognit + - gci + - goconst + - gocritic + - gocyclo + - godot + # - godox + # - goerr113 + - gofmt + - goheader + - goimports + - gomodguard + # - gomnd + - goprintffuncname + - gosec + - gosimple + - govet + - ineffassign + - lll + # - maligned + - misspell + - nakedret + # - nestif + - noctx + - nolintlint + # - prealloc + - revive + - rowserrcheck + - staticcheck + - stylecheck + # - testpackage + - typecheck + - unconvert + - unparam + - unused + - whitespace + # - wsl + +issues: + #fix: true + + max-issues-per-linter: 0 + max-same-issues: 0 + + # Disable the default exclude patterns (as they disable the mandatory comments) + exclude-use-default: false + exclude: + # errcheck: Almost all programs ignore errors on these functions and in most cases it's ok + - Error return value of .((os\.)?std(out|err)\..*|.*Close|.*Flush|os\.Remove(All)?|.*printf?|os\.(Un)?Setenv). is not checked + + exclude-rules: + - linters: + - govet + text: 'declaration of "(err|ctx)" shadows declaration at' + - linters: + - gosec + # Disable the check to test that HTTP clients are not using an insecure TLS connection. + # We need it to contact the remote authentication services exposing a self-signed certificate + text: TLS InsecureSkipVerify set true. + - linters: + - errorlint + # Disable the check to test errors type assertion on switches. + text: type switch on error will fail on wrapped errors. Use errors.As to check for specific errors + + # Exclude the following linters from running on tests files. + - path: _test\.go + linters: + - whitespace diff --git a/.markdownlint.yml b/.markdownlint.yml new file mode 100644 index 0000000..802a7af --- /dev/null +++ b/.markdownlint.yml @@ -0,0 +1,5 @@ +default: true +line-length: false +no-inline-html: false +no-duplicate-header: + siblings_only: true \ No newline at end of file diff --git a/.markdownlintignore b/.markdownlintignore new file mode 100644 index 0000000..e9a3bdc --- /dev/null +++ b/.markdownlintignore @@ -0,0 +1,2 @@ +deployments +docs/_legacy \ No newline at end of file diff --git a/README.md b/README.md index 96dcbb1..7867405 100644 --- a/README.md +++ b/README.md @@ -1,16 +1,20 @@ +# +

WP3 - FLUIDOS Node

## What is a FLUIDOS Node? + A FLUIDOS node is orchestrated by a single Kubernetes control plane, and it can be composed of either a single device or a set of devices (e.g., a datacenter). Device homogeneity is desired in order to simplify the management (physical servers can be considered all equals, since they feature a similar amount of hardware resources), but it is not requested within a FLUIDOS node. In other words, a FLUIDOS node corresponds to a *Kubernetes cluster*. ## What can I find in this repo? -This repository contains the FLUIDOS Node, along with its essential components, such as: + +This repository contains the FLUIDOS Node, along with its essential components, such as: - [**Local ResourceManager**](/docs/implementation/components.md#local-resourcemanager) -- [**Avaialable Resources**](/docs/implementation/components.md#available-resources) +- [**Avaialable Resources**](/docs/implementation/components.md#available-resources) - [**Discovery Manager**](/docs/implementation/components.md#discovery-manager) - [**Peering Candidates**](/docs/implementation/components.md#peering-candidates) - [**REAR Manager**](/docs/implementation/components.md#rear-manager) @@ -19,10 +23,13 @@ This repository contains the FLUIDOS Node, along with its essential components, Please note that this repository is continually updated, with additional components slated for future inclusion. ## Implementation + Want to know more about the implementation? Check out the [**Implementation Part**](./docs/implementation/implementation.md). ## Installation + Want to know how to install a FLUIDOS Node? Check out the [**Installation Part**](./docs/installation/installation.md). ## License -This project is licensed under the Apache License 2.0 - see the [LICENSE](LICENSE) file for details. \ No newline at end of file + +This project is licensed under the Apache License 2.0 - see the [LICENSE](LICENSE) file for details. diff --git a/docs/implementation/components.md b/docs/implementation/components.md index f4e2de1..1428f63 100644 --- a/docs/implementation/components.md +++ b/docs/implementation/components.md @@ -1,4 +1,5 @@ -## Components +# Components + Let's see how each component has been implemented: - [**Local ResourceManager**](#local-resourcemanager) @@ -8,10 +9,12 @@ Let's see how each component has been implemented: - [**REAR Manager**](#rear-manager) - [**Contract Manager**](#contract-manager) -### Local ResourceManager +## Local ResourceManager + The **Local Resource Manager** was constructed through the development of a Kubernetes controller. This controller serves the purpose of monitoring the internal resources of individual nodes within a FLUIDOS Node, representing a cluster. Subsequently, it generates a *Flavour Custom Resource (CR)* for each node and stores these CRs within the cluster for further management and utilization. -### Available Resources +## Available Resources + **Available Resources** component is a critical part of the FLUIDOS system responsible for managing and storing Flavours. It consists of two primary data structures: 1. **Free Flavours**: This section is dedicated to storing Flavours, as defined in the REAR component. @@ -21,32 +24,37 @@ The **Local Resource Manager** was constructed through the development of a Kube The primary function of Available Resources is to serve as a centralized repository for Flavours. When queried, it provides a list of these resources. Under the hood, Available Resources seamlessly integrates with Kubernetes' `etcd`, ensuring efficient storage and retrieval of data. This component plays a crucial role in facilitating resource management within the FLUIDOS ecosystem, enabling efficient allocation and utilization of computing resources. -### Discovery Manager + +## Discovery Manager + The **Discovery Manager** component within the FLUIDOS system serves as a critical part of the resource discovery process. It operates as a Kubernetes controller, continuously monitoring Discovery Custom Resources (CRs) generated by the Solver Controller. The primary objectives of the Discovery Manager are as follows: - **Populating Peering Candidates Table (Client)**: The Discovery Manager's primary responsibility is to populate the Peering Candidates table. It achieves this by identifying suitable resources known as "Flavours" based on the initial messages exchanged as part of the REAR protocol. -- **Discovery (Client)**: it initiates a LIST_FLAVOURS message, broadcasting it to all known list of FLUIDOS Nodes. +- **Discovery (Client)**: it initiates a LIST_FLAVOURS message, broadcasting it to all known list of FLUIDOS Nodes. - **Offering Appropriate Flavours (Provider)**: In response to incoming requests, it will provide Flavours that best match the specific request. -### Peering Candidates +## Peering Candidates + The **Peering Candidates** component manages a dynamic list of nodes that are potentially suitable for establishing peering connections. This list is continuously updated by the Discovery Manager. -Under the hood, Peering Candidates are stored through an appropriate Custom Resource. +Under the hood, Peering Candidates are stored through an appropriate Custom Resource. -### REAR Manager -The **REAR Manager** plays a pivotal role in orchestrating the service provisioning process. It receives a solving request, translates them into resource or service requests, and looks up external suitable resources: +## REAR Manager -- If no Peering Candidates are found, it initiates the **Discovery**. -- Optionally, if a suitable candidate is found, it triggers the **Reservation** phase. +The **REAR Manager** plays a pivotal role in orchestrating the service provisioning process. It receives a solving request, translates them into resource or service requests, and looks up external suitable resources: + +- If no Peering Candidates are found, it initiates the **Discovery**. +- Optionally, if a suitable candidate is found, it triggers the **Reservation** phase. - If this process is successfully fulfilled, resources are allocated, contracts are stored, and optionally can start the **Peering** phase. -### Contract Manager +## Contract Manager + The Contract Manager is in charge of managing the reserve and purchase of resources. It handles the negotiation and management of resource contracts between nodes: - When a suitable peering candidate is identified and a Reservation is forged, the Contract Manager initiates the `Reserve` phase by sending a **RESERVE\_FLAVOUR** message. -- Upon successful reservation of resources, it proceeds to the `Purchase` phase by sending a **PURCHASE\_FLAVOUR** message. Following this, it stores the contract received. \ No newline at end of file +- Upon successful reservation of resources, it proceeds to the `Purchase` phase by sending a **PURCHASE\_FLAVOUR** message. Following this, it stores the contract received. diff --git a/docs/implementation/controllers.md b/docs/implementation/controllers.md index dc1f25a..b96c924 100644 --- a/docs/implementation/controllers.md +++ b/docs/implementation/controllers.md @@ -1,12 +1,14 @@ -## Controllers +# Controllers + In the following, the controllers developed for the FLUIDOS Node are described. To see the different objects, see [**Custom Resources**](./customresources.md#custom-resources) part. -### Solver Controller (`solver_controller.go`) +## Solver Controller (`solver_controller.go`) + The Solver controller, tasked with reconciliation on the `Solver` object, continuously monitors and manages its state to ensure alignment with the desired configuration. It follows the following steps: 1. When there is a new Solver object, it firstly checks if the `Solver` has expired or failed (if so, it marks the Solver as `Timed Out`). -2. It checks if the Solver has to find a candidate. -3. If so, it starts to search a matching Peering Candidate if available. +2. It checks if the Solver has to find a candidate. +3. If so, it starts to search a matching Peering Candidate if available. 4. If some Peering Candidates are available, it selects one and book it. 5. If no Peering Candidates are available, it starts the discovery process by creating a `Discovery`. 6. If the `findCandidate` status is solved, it means that a Peering Candidate has been found. Otherwise, it means that the `Solver` has failed. @@ -15,15 +17,17 @@ The Solver controller, tasked with reconciliation on the `Solver` object, contin 9. If the `Reservation` is successfully fulfilled, it means that the `Solver` has reserved and purchased the resources. Otherwise, it means that the `Solver` has failed. 10. If in the `Solver` there is also a `EnstablishPeering` phase, it starts the peering process (to be implemented). Otherwise, it ends the process. -### Discovery Controller (`discovery_controller.go`) +## Discovery Controller (`discovery_controller.go`) + The Discovery controller, tasked with reconciliation on the `Discovery` object, continuously monitors and manages its state to ensure alignment with the desired configuration. It follows the following steps: 1. When there is a new Discovery object, it firstly starts the discovery process by contacting the `Gateway` to discover flavours that fits the `Discovery` selector. -2. If no flavours are found, it means that the `Discovery` has failed. Otherwise, it refers to the first `PeeringCandidate` as the one that will be reserved (more complex logic should be implemented), while the other will be stored as not reserved. +2. If no flavours are found, it means that the `Discovery` has failed. Otherwise, it refers to the first `PeeringCandidate` as the one that will be reserved (more complex logic should be implemented), while the other will be stored as not reserved. 3. It update the `Discovery` object with the `PeeringCandidates` found. 4. The `Discovery` is solved, so it ends the process. -### Reservation Controller (`reservation_controller.go`) +## Reservation Controller (`reservation_controller.go`) + The Reservation controller, tasked with reconciliation on the `Reservation` object, continuously monitors and manages its state to ensure alignment with the desired configuration. It follows the following steps: 1. When there is a new `Reservation` object it checks if the `Reserve` flag is set. If so, it starts the **Reserve** process. @@ -33,10 +37,8 @@ The Reservation controller, tasked with reconciliation on the `Reservation` obje 5. Using the `Transaction` object from the `Reservation`, it starts the purchase process. 6. If the purchase phase is successfully fulfilled, it will update the status of the `Reservation` object and it will store the received `Contract`. Otherwise, the `Reservation` has failed. +## Allocation Controller (`allocation_controller.go`) -### Allocation Controller (`allocation_controller.go`) The Allocation controller, tasked with reconciliation on the `Allocation` object, continuously monitors and manages its state to ensure alignment with the desired configuration. (To be implemented) - - diff --git a/docs/implementation/customresources.md b/docs/implementation/customresources.md index 9d8874b..c4f256a 100644 --- a/docs/implementation/customresources.md +++ b/docs/implementation/customresources.md @@ -1,4 +1,5 @@ -## Custom Resources +# Custom Resources + The following custom resources have been developed for the FLUIDOS Node: - [**Discovery**](./customresources.md#discovery) @@ -10,7 +11,8 @@ The following custom resources have been developed for the FLUIDOS Node: - [**Solver**](./customresources.md#solver) - [**Transaction**](./customresources.md#transaction) -### Discovery +## Discovery + Here is a `Discovery` sample: ```yaml @@ -29,7 +31,8 @@ spec: subscribe: true ``` -### Reservation +## Reservation + Here is a `Reservation` sample: ```yaml @@ -54,11 +57,13 @@ spec: nodeID: 91cbd32s0q1 ``` -### Allocation +## Allocation + To be implemented. -### Flavour -Here is a `Flavour` sample: +## Flavour + +Here is a `Flavour` sample: ```yaml apiVersion: nodecore.fluidos.eu/v1alpha1 @@ -89,7 +94,8 @@ spec: type: k8s-fluidos ``` -### Contract +## Contract + Here is a `Contract` sample: ```yaml @@ -147,7 +153,8 @@ Spec: nodeID: 91cbd32s0q1 ``` -### PeeringCandidate +## PeeringCandidate + Here is a `PeeringCandidate` sample: ```yaml @@ -188,7 +195,8 @@ Spec: Solver ID: solver1 ``` -### Solver +## Solver + Here is a `Solver` sample: ```yaml @@ -208,7 +216,8 @@ spec: enstablishPeering: false ``` -### Transaction +## Transaction + Here is a `Transaction` sample: ```yaml @@ -218,4 +227,4 @@ Kind: Transaction Spec: Flavour ID: k8s-fluidos-002 Start Time: 2023-09-29T11:26:37+02:00 -``` \ No newline at end of file +``` diff --git a/docs/implementation/implementation.md b/docs/implementation/implementation.md index b255077..693dc08 100644 --- a/docs/implementation/implementation.md +++ b/docs/implementation/implementation.md @@ -1,4 +1,5 @@ # Implementation + Regarding the implementation part, the components have been developed using **Kubernetes controllers** with Kubebuilder, making extensive use of the *Kubernetes API* and *Custom Resource Definitions (CRDs)*. Implementation is divided into three main parts: @@ -11,8 +12,8 @@ Implementation is divided into three main parts:

-See the different implementation for: +See the different implementation for: - [**Components**](./components.md#components) - [**Controllers**](./controllers.md#controllers) -- [**Custom Resources**](./customresources.md#custom-resources) \ No newline at end of file +- [**Custom Resources**](./customresources.md#custom-resources) diff --git a/docs/installation/installation.md b/docs/installation/installation.md index 2fd9f95..e69de29 100644 --- a/docs/installation/installation.md +++ b/docs/installation/installation.md @@ -1 +0,0 @@ -TBD \ No newline at end of file diff --git a/docs/quickstart/quickstart.md b/docs/quickstart/quickstart.md index 2fd9f95..e69de29 100644 --- a/docs/quickstart/quickstart.md +++ b/docs/quickstart/quickstart.md @@ -1 +0,0 @@ -TBD \ No newline at end of file diff --git a/examples/kind/README.md b/examples/kind/README.md index d24d9d5..7e3937f 100644 --- a/examples/kind/README.md +++ b/examples/kind/README.md @@ -1,12 +1,15 @@ +# +

FLUIDOS Node - KIND Installation

## Getting Started + This guide will help you to install a FLUIDOS Node on a Kubernetes cluster using KIND (Kubernetes in Docker). This is the easiest way to install FLUIDOS Node on a local machine. -This guide has been made only for testing purposes. If you want to install FLUIDOS Node on a production environment, please follow the [official installation guide](#) +This guide has been made only for testing purposes. If you want to install FLUIDOS Node on a production environment, please follow the [official installation guide](/docs/installation/installation.md) ## What will be installed @@ -17,6 +20,7 @@ This guide will create two different Kubernetes clusters: * **fluidos-provider**: This cluster will act as a provider of the FLUIDOS Node. It will offer its own Flavours on the specific request made by the consumer, reserving and selling it. ### Prerequisites + * [Docker](https://docs.docker.com/get-docker/) * [Kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) * [KIND](https://kind.sigs.k8s.io/docs/user/quick-start/#installation) @@ -24,56 +28,65 @@ This guide will create two different Kubernetes clusters: ### Installation -1. Clone the repository -```sh +* Clone the repository + +```sh git clone https://github.com/fluidos-project/node.git ``` -2. Move into the KIND Example folder +* Move into the KIND Example folder + ```sh cd examples/kind ``` -3. Launch the `setup.sh` script +* Launch the `setup.sh` script + ```sh . ./setup.sh ``` -4. Wait for the script to finish. It will take some minutes. +* Wait for the script to finish. It will take some minutes. + +* When the script has finished, you can check the status of the pods with the following command: -5. When the script has finished, you can check the status of the pods with the following command: ```sh kubectl get pods -n fluidos ``` -1. You should see 3 pods running on the `fluidos-consumer` cluster and 3 pods running on the `fluidos-provider` cluster: +* You should see 3 pods running on the `fluidos-consumer` cluster and 3 pods running on the `fluidos-provider` cluster: -- `node-local-reaource-manager-` -- `node-rear-manager-` -- `node-rear-controller-` +* `node-local-reaource-manager-` +* `node-rear-manager-` +* `node-rear-controller-` ### Usage -Now lets try to deploy a `solver` example CR on the `fluidos-consumer` cluster. +Now lets try to deploy a `solver` example CR on the `fluidos-consumer` cluster. + +* Open a new terminal on the repo and move into the `deployments/samples` folder -1. Open a new terminal on the repo and move into the `deployments/samples` folder ```sh cd deployments/samples ``` -2. Set the `KUBECONFIG` environment variable to the `fluidos-consumer` cluster +* Set the `KUBECONFIG` environment variable to the `fluidos-consumer` cluster + ```sh export KUBECONFIG=../../examples/kind/consumer/config ``` -3. Deploy the `solver` CR + +* Deploy the `solver` CR + ```sh kubectl apply -f solver.yaml ``` -1. Check the result of the deployment +* Check the result of the deployment + ```sh kubectl get solver -n fluidos ``` -1. The output should be something like -`` \ No newline at end of file +* The output should be something like +`` diff --git a/examples/kind/setup.sh b/examples/kind/setup.sh index 9c877cd..9b0adc1 100644 --- a/examples/kind/setup.sh +++ b/examples/kind/setup.sh @@ -5,8 +5,8 @@ set -xeu consumer_node_port=30000 provider_node_port=30001 -kind create cluster --config consumer/cluster-multi-worker.yaml --name fluidos-consumer --kubeconfig $PWD/consumer/config -kind create cluster --config provider/cluster-multi-worker.yaml --name fluidos-provider --kubeconfig $PWD/provider/config +kind create cluster --config consumer/cluster-multi-worker.yaml --name fluidos-consumer --kubeconfig "$PWD/consumer/config" +kind create cluster --config provider/cluster-multi-worker.yaml --name fluidos-provider --kubeconfig "$PWD/provider/config" consumer_controlplane_ip=$(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' fluidos-consumer-control-plane) provider_controlplane_ip=$(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' fluidos-provider-control-plane) @@ -16,7 +16,7 @@ helm repo add fluidos https://fluidos-project.github.io/node/ export KUBECONFIG=$PWD/consumer/config kubectl apply -f ../../deployments/node/crds -kubectl apply -f $PWD/metrics-server.yaml +kubectl apply -f "$PWD/metrics-server.yaml" echo "Waiting for metrics-server to be ready" kubectl wait --for=condition=ready pod -l k8s-app=metrics-server -n kube-system --timeout=300s