From 5ea912f697ef9b9faedd5959c1faa2dddd75418d Mon Sep 17 00:00:00 2001 From: Madhur Shrimal Date: Thu, 26 Oct 2023 11:15:24 -0700 Subject: [PATCH 1/5] remove install and montoring --- docs/docs/introduction.md | 3 +- docs/docs/spec/intro.md | 5 +- docs/docs/spec/packaging/_category_.json | 8 - docs/docs/spec/packaging/guidelines.md | 83 - docs/docs/spec/packaging/manifest.md | 114 - docs/docs/spec/packaging/packaging.mdx | 199 - docs/docs/spec/packaging/profiles.md | 531 - docs/docs/spec/packaging/reference.md | 198 - docs/docs/spec/packaging/upgrading.md | 56 - docs/docs/spec/plugin/intro.mdx | 21 +- docs/docs/wizard/_category_.json | 9 - docs/docs/wizard/backup/_category_.json | 9 - docs/docs/wizard/backup/backup.md | 42 - docs/docs/wizard/backup/intro.md | 23 - docs/docs/wizard/backup/restore.md | 33 - docs/docs/wizard/intro.md | 34 - docs/docs/wizard/monitoring/_category_.json | 8 - docs/docs/wizard/monitoring/grafana.md | 40 - docs/docs/wizard/monitoring/intro.md | 48 - docs/docs/wizard/monitoring/node-exporter.md | 6 - docs/docs/wizard/monitoring/prometheus.md | 6 - docs/yarn.lock | 19646 +++++++---------- 22 files changed, 8182 insertions(+), 12940 deletions(-) delete mode 100644 docs/docs/spec/packaging/_category_.json delete mode 100644 docs/docs/spec/packaging/guidelines.md delete mode 100644 docs/docs/spec/packaging/manifest.md delete mode 100644 docs/docs/spec/packaging/packaging.mdx delete mode 100644 docs/docs/spec/packaging/profiles.md delete mode 100644 docs/docs/spec/packaging/reference.md delete mode 100644 docs/docs/spec/packaging/upgrading.md delete mode 100644 docs/docs/wizard/_category_.json delete mode 100644 docs/docs/wizard/backup/_category_.json delete mode 100644 docs/docs/wizard/backup/backup.md delete mode 100644 docs/docs/wizard/backup/intro.md delete mode 100644 docs/docs/wizard/backup/restore.md delete mode 100644 docs/docs/wizard/intro.md delete mode 100644 docs/docs/wizard/monitoring/_category_.json delete mode 100644 docs/docs/wizard/monitoring/grafana.md delete mode 100644 docs/docs/wizard/monitoring/intro.md delete mode 100644 docs/docs/wizard/monitoring/node-exporter.md delete mode 100644 docs/docs/wizard/monitoring/prometheus.md diff --git a/docs/docs/introduction.md b/docs/docs/introduction.md index 2e97b6ff..02ae6889 100644 --- a/docs/docs/introduction.md +++ b/docs/docs/introduction.md @@ -6,12 +6,11 @@ sidebar_position: 0 The [EigenLayer](https://www.eigenlayer.xyz/) ecosystem allows Ethereum validators to restake their ETH and provide services to the network, such as a Data Availability Layer with a particular type of node software called [Actively Validated Services (AVS)](/docs/glossary#avs-actively-validated-service). -With the increasing number of AVS use cases, there is a need for a convention on how to develop, maintain, create interoperability, and monitor them. Eigenlayer has partnered with Nethermind to create an [AVS Node](/docs/glossary#avs-node) Specification with those goals in mind. We also decided to build an AVS Node Setup Wizard to install and manage AVS Nodes that follow such specification. This documentation describes the AVS Node Specification and the AVS Node Setup Wizard. +With the increasing number of AVS use cases, there is a need for a convention on how to develop, maintain, create interoperability, and monitor them. Eigenlayer has partnered with Nethermind to create an [AVS Node](/docs/glossary#avs-node) Specification with those goals in mind. This documentation describes the AVS Node Specification. The documentation is divided into the following sections: - [AVS Node Specification](/docs/category/avs-node-specification): A full description of the specification that covers from AVS packaging to Standard Metrics. -- [Setup wizard](/docs/category/avs-setup-wizard): An AVS setup wizard tool aimed to simplify AVS Node management for node operators. - [Keys Management](/docs/category/keys-management): Good practices for keys management. ## Definitions diff --git a/docs/docs/spec/intro.md b/docs/docs/spec/intro.md index 49e9b808..09d15f5c 100644 --- a/docs/docs/spec/intro.md +++ b/docs/docs/spec/intro.md @@ -3,7 +3,7 @@ title: "Introduction" sidebar_position: 1 --- -This is a specification for the packaging, installation, update, and monitoring process of [EigenLayer](https://www.eigenlayer.xyz/) Nodes. AVS is used to participate in the EigenLayer restaking system, to know more about EigenLayer see its [documentation page](https://docs.eigenlayer.xyz/overview/readme). +This is a specification for running of [EigenLayer](https://www.eigenlayer.xyz/) Nodes. AVS is used to participate in the EigenLayer restaking system, to know more about EigenLayer see its [documentation page](https://docs.eigenlayer.xyz/overview/readme). The current version of the specification is `v0.0.1`. @@ -15,7 +15,6 @@ The current version of the AVS Node specification should be considered a public The description of the Specification is divided into the following sections: -- [Packaging & Upgrading](/docs/spec/packaging/): How developers can package their AVS Nodes and how an AVS wizard setup tool can install and upgrade them. - [AVS Node API](/docs/category/avs-node-api): HTTP RESTful API for AVS Nodes. - [Metrics](/docs/category/metrics): Prometheus standard metrics for AVS implementations. -- [Plugin](/docs/spec/plugin/intro): How developers can provide a plugin to extend the AVS wizard setup tool with AVS-specific features. +- [Plugin](/docs/spec/plugin/intro): How developers can provide a interface to execute on-time features. diff --git a/docs/docs/spec/packaging/_category_.json b/docs/docs/spec/packaging/_category_.json deleted file mode 100644 index a1a7a186..00000000 --- a/docs/docs/spec/packaging/_category_.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "label": "Packaging & Upgrading", - "position": 1, - "link": { - "type": "generated-index", - "description": "Packaging and Upgrading procedures" - } -} diff --git a/docs/docs/spec/packaging/guidelines.md b/docs/docs/spec/packaging/guidelines.md deleted file mode 100644 index 20de663e..00000000 --- a/docs/docs/spec/packaging/guidelines.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -sidebar_position: 5 -id: guidelines ---- -# Packaging Best Practices - -- [Packaging Best Practices](#packaging-best-practices) - - [How to handle docker images](#how-to-handle-docker-images) - - [Tags usage](#tags-usage) - - [Why docker image builds are not supported](#why-docker-image-builds-are-not-supported) - - [Avoid using `container_name`](#avoid-using-container_name) - - [Docker Compose elements that should be profile options](#docker-compose-elements-that-should-be-profile-options) - - [When to create an additional profile](#when-to-create-an-additional-profile) - - [Create a separate repository for the AVS package](#create-a-separate-repository-for-the-avs-package) - - [Use the `hidden` field of profile's options for sensitive information](#use-the-hidden-field-of-profiles-options-for-sensitive-information) - - [Use Docker Volumes for persisting data](#use-docker-volumes-for-persisting-data) - - -The following represents a set of guidelines, rules, and recommendations on managing and creating the AVS package. - -:::tip - -The [reference package](/docs/spec/packaging/reference) and the [mock-avs-pkg](https://github.com/NethermindEth/mock-avs-pkg)(dummy AVS used for testing purposes) are good examples of how to follow these guidelines. - -::: - -## How to handle docker images - -The specification **DOES NOT** support docker image builds. You can't use the [`build`](https://docs.docker.com/compose/compose-file/compose-file-v3/#build) field on the `docker-compose.yml` file. The Compose script **MUST** refer to docker images in a Docker registry. For development purposes, you can use a local docker image. - -An alternative to target the entire docker image name as a profile option is to fix the name but let the tag open for modification. An env variable with a bounded profile option is also recommended in this case. - -Examples of both profile options usage for the full docker image name and only the tag can be found in the [reference package](/docs/spec/packaging/reference). Notice that the name is fixed for the Postgres docker image, but the tag is used as a profile option. - -### Tags usage - -**AVOID** using the default tag `latest`. This might bring issues among different package versions. You **SHOULD** use unique tags that identify a fixed version of the containerized application you want the user to run. - -### Why docker image builds are not supported - -The issues around building docker images can be summarized: - -- **Introduce vulnerabilities and security concerns** to the user’s host machine because **builds could execute arbitrary and potentially malicious code**. Currently, the attack surface is quite extensive as anyone with write access to the AVS Tap repo could add this type of code and change the AVS Node docker build pipeline or Docker Compose, create a git tag and make a release. -- Supporting docker image builds **involves cloning and using the entire repository** where the AVS package lies. This means not only that we are potentially copying a lot of unnecessary data for the user into his/her disk and making the installation process heavier than necessary, but also that we can’t control the usage of good practices around the AVS packaging. If, for example, we would like to enforce creating a separate repository for the AVS package only, it wouldn’t be possible if we allow docker builds. -- Depending on docker builds for the users to use your software **is not a good practice**. An AVS developer will likely push the Docker images to a Docker registry. Maintaining two different ways of using your official Docker Compose script is a burden, as there are differences between using already-built images and building images from a local/remote context. Building the docker image could be helpful for development environments. However, it **is not expensive to build your image** before running your Compose script and target the local image inside it. AVS developers could add a simple `docker build` command to their build scripts or E2E test setup parts, use an env variable for the `image` field of the Compose script, and only change the env variable value. This introduces a new problem: which tag to use for the docker image. We are going to cover that in the next section. - -## Avoid using [`container_name`](https://docs.docker.com/compose/compose-file/compose-file-v3/#container_name) - -Using the [`container_name`](https://docs.docker.com/compose/compose-file/compose-file-v3/#container_name) field of the Docker Compose Specification introduces the risk of name collision between two containers run with different instances of the same `docker-compose.yml`. - -This issue can be tackled by defining the container name as a profile option. The 'main-container-name' profile option is used in the [reference package](/docs/spec/packaging/reference) for this purpose. This way, the user can use a new container name for different AVS package instances or change the default container name. - -Docker Compose has a smart way of setting up a container name of a Compose service if the [`container_name`](https://docs.docker.com/compose/compose-file/compose-file-v3/#container_name) field is not provided. You can rely on Compose for this naming. - -## Docker Compose elements that should be profile options - -Some common use cases will benefit from profile options: - -- **Bind-mount volumes:** This kind of volume usually requires a path inside the host machine to the desired folder or file to bind. Using a default path here will be far from ideal in many cases. We strongly recommend always using an env variable for this path with a profile option. In the [reference package](/docs/spec/packaging/reference), the `KEYSTORE_PATH` env variable is used for this purpose. Notice the usage of the profile option type `path_dir` for this env variable. Any path option should be used similarly. -- **Container names:** As mentioned above, using the [`container_name`](https://docs.docker.com/compose/compose-file/compose-file-v3/#container_name) field of the Docker Compose Specification introduces the risk of name collision between two containers run with different instances of the same `docker-compose.yml`. This issue can be tackled by defining the container name as a profile option like in the [reference package](/docs/spec/packaging/reference). This way, the user can use a new container name for different AVS package instances or change the default container name. -- **Docker image names:** Putting any Docker images as profile options is strongly recommended. In the [reference package](/docs/spec/packaging/reference), a `validate.re2_regex` is provided to validate docker image names. Notice that the name is fixed for the Postgres docker image, but the tag is used as a profile option. This is a recommended practice as well. -- **Ports:** Ports are a typical profile option. The' main-service-port' is a profile option in the [reference package](/docs/spec/packaging/reference). Notice that the `main-service-port` is also a `target` for the `monitoring` section. Profile options for ports **MUST** to be of type `port` and have a default value. This allows port collision checks between multiple Nodes running in the same host machine. You **MUST** target the port part of the Host machine. The container port should be fixed, not a profile option (ports are defined as `HOST_PORT:CONTAINER_PORT`). - -## When to create an additional profile - -Suppose you find yourself creating profile options for settings whose values are common within several instances of the AVS Node (different instances of the same AVS Node running on the same network). In that case, chances are these values should be fixed, and you will benefit from creating profiles for combinations of these settings (different networks, Node modes, etc.). In this case, creating an additional profile might allow you to define fewer profile options. Less profile options mean fewer settings to maintain and fewer settings for the user to configure. - -## Create a separate repository for the AVS package - -We **strongly recommend** creating a separate repository (Tap) for the AVS package. This has several benefits: - -- The AVS Tap repository and root folder can be listed in a public index in a clean way without anything additional to the AVS package. -- It is easier to restrict access to the Tap repository. For instance, if the AVS package is within the AVS node repository, all the contributors could make changes to the AVS package. -- It doesn’t constrain your AVS Node repository to be public. Although it is recommended to make your AVS Node source code open-source, nothing will stop a developer from making an AVS Node closed (this is often done in the first stages of development). This closed AVS Nodes could have their packages public if they dedicate a separate repository. -- Downloading the AVS package would be very light and fast. - -## Use the `hidden` field of profile's options for sensitive information - -The `hidden` field of profile's options allows you to hide the value of the option in the AVS setup wizard tool. This is a recommended practice for sensitive information. The option keeps the `validate` and the `type` fields to ensure that the user provides a valid value, but the `default` field will be ignored. - -## Use Docker Volumes for persisting data - -Docker Volumes (named and bind-mount volumes) are recommended to persist data outside the container. If you don't use volumes, the data will be lost when the container is removed. The `db-service` service representing the Postgres database uses a named volume for this purpose (check [reference package](/docs/spec/packaging/reference)). The `main-service` uses a bind-mount volume. Both are valid options. For more information about Docker Volumes, check the [Docker documentation](https://docs.docker.com/storage/volumes/). \ No newline at end of file diff --git a/docs/docs/spec/packaging/manifest.md b/docs/docs/spec/packaging/manifest.md deleted file mode 100644 index f98d93b2..00000000 --- a/docs/docs/spec/packaging/manifest.md +++ /dev/null @@ -1,114 +0,0 @@ ---- -sidebar_position: 2 -id: manifest ---- - -# Manifest file - -The Manifest file is an essential component of the AVS Node package structure. It provides crucial information about the AVS version, its name, and the list of profiles that are included in the package. The `upgrade` field of the Manifest file indicates whether an upgrade is optional, recommended, or required, which allows users to determine how and when to upgrade their AVS to the latest version. - -Additionally, the Manifest file specifies the structure of the AVS package, which includes a `profile` folder and a `manifest.yml` file. The `profile` folder contains a Docker Compose file, an `.env` file with default values for environment variables, and the `profile.yml` configuration file. This folder structure ensures that all the necessary files to set up the AVS Node in an on-premise setup using Docker Compose as a service manager are included in the package. - -The `manifest.yml` file specifies the version of the specification, the AVS Node name, hardware requirements for the AVS Node, information about the AVS provided [plugin](#plugin), and a list of profiles. The profile list includes the name of each profile and its relative path within the package. This information is crucial for users to understand what profiles are available and how to access them within the package. - -The file’s name **MUST** be `manifest.yml`. - -## Manifest format - -```yaml -# AVS Specification version -version: - -# Name of the AVS Node -name: - -# Upgrade recommendation: optional, recommended, required -upgrade: - -# Hardware Requirements -hardware_requirements: - -# Plugin source -plugin: - -# List of AVS package profiles -profiles: -[ - ] -``` - -### `` - -```yaml -# Minimum number of CPU cores -min_cpu_cores: - -# Minimum free memory space needed to run this profile in MiB -min_ram: - -# Minimum free disk space needed to run this profile in MiB -min_free_space: - -# true if setup should not proceed if any hardware requirement is not met -stop_if_requirements_are_not_met: -``` - -### `` - -See [plugin documentation](/docs/spec/plugin/intro) to learn more about the plugin system. - -```yaml -# Pre-built image name ready to be pulled. -image: -``` - -## Manifest schema - -```yaml -$schema: "http://json-schema.org/draft-07/schema#" -type: object -properties: - version: - type: string - name: - type: string - upgrade: - type: string - hardware_requirements: - type: object - properties: - min_cpu_cores: - type: integer - minimum: 0 - min_ram: - type: integer - minimum: 0 - min_free_space: - type: integer - minimum: 0 - stop_if_requirements_are_not_met: - type: boolean - required: - - min_cpu_cores - - min_ram - - min_free_space - - stop_if_requirements_are_not_met - additionalProperties: false - plugin: - type: object - properties: - image: - type: string - additionalProperties: false - required: - - image - profiles: - type: array - minItems: 1 - items: - type: string -required: -- version -- name -- profiles -additionalProperties: false -``` \ No newline at end of file diff --git a/docs/docs/spec/packaging/packaging.mdx b/docs/docs/spec/packaging/packaging.mdx deleted file mode 100644 index 73bbf7e5..00000000 --- a/docs/docs/spec/packaging/packaging.mdx +++ /dev/null @@ -1,199 +0,0 @@ ---- -sidebar_position: 1 -id: packaging ---- - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -# Packaging procedure - -AVS Nodes in the EigenLayer Protocol under the proposed specification comprise of Docker containers running alongside backing services such as databases, indexers, and utility services. Developers are responsible for defining these services and their options well to work correctly. The objective is to create a standard interface to manage the setup, configuration, and updates of these AVS Nodes. - -The package for a specific version of an AVS Node will consist of a **`docker-compose.yml`** file, a manifest file defining the package version and additional information (if the upgrade is optional or recommended, etc), and a set of profiles or different configurations for the package. - -Developers will publish their packages following the format defined [below](#node-package) in a git repository (Tap), which involves developers initializing a git repository with the required and standard structure that will be defined later. The [AVS setup wizard](/docs/category/avs-setup-wizard) would rely on this structure to get package information and install the AVS Node. - -The Tap can be within the AVS source code repository or in a separate repository. [We recommend the latter](/docs/spec/packaging/guidelines#create-a-separate-repository-for-the-avs-package). If the Tap is in a separate repository, the Tap's name **MUST** be suffixed with `-pkg` to differentiate it from the AVS source code repository. For example, if the AVS source code repository is called `foo-avs`, the Tap repository should be called `foo-avs-pkg`. - -Developers manage these repositories, and with each new release, they update the tap with the corresponding configuration files. The new package will only be considered correct if it follows the required structure and if a git tag that represents proper [semantic versioning](https://semver.org) is created with it in the tap repository. - -The EigenLayer organization will maintain a core git repository that will serve as an index for all the published AVS containing the URLs of all the packaging repositories. Developers have to create a Pull Request to this core repository to register their AVS. - -As an **alternative to centralized git hosting**, we suggest using distributed ledger technology (DLT), such as a blockchain, to store and manage AVS configuration files and metadata. Developers would submit their configuration files, updates, and other relevant information to the DLT network. - -This approach would require Developers to interact with the DLT network, submitting transactions and querying data. As a result, the management process becomes decentralized and transparent. - -Decentralized git hosting such as [Gitopia](https://gitopia.com) can be used as an alternative to Github. - -:::caution - -While this decentralized approach is interesting and offers some unique benefits, it may not be the most practical solution for managing AVS due to the added complexity and potential performance issues. However, it's worth considering as an alternative to more traditional centralized or repository-based approaches. - -::: - -:::caution - -The EigenLayer AVS Specification is designed for **Linux** systems. The packaging structure and its functionality rely on the use of Docker and Docker Networking, including host networking, which needs to be better supported on Windows and Mac OS. - -::: - -## AVS Node package - -An AVS Node ultimately is a collection of Docker services declared in a Docker Compose file. Developers are responsible for defining these services and their options well to work correctly. - -The objective of an AVS package is to provide all the necessary files to set up an AVS Node in an on-premise setup using [Docker Compose](https://docs.docker.com/compose/) as a service manager. - -### Package source - -- Git repository - -### Structure - -A package is a set of profiles, which means each AVS version could have a collection of profiles inside that the user could select at setup time, like the following: - -``` -eigenlayer install some/avs -v v1.0.0 [profile] [options...] -``` - -:::note - - - -::: - -Profiles are suitable for creating specialized setups of the same version for different scenarios like different networks. - -The `manifest.yml` file at the project's root is the entry point to define the project's structure, with information about the package and the list of profiles. - -``` -./ -├── profile1/ -│ ├── .env -│ ├── docker-compose.yml -│ └── profile.yml -├── profile2/ -│ ├── .env -│ ├── docker-compose.yml -│ └── profile.yml -└── manifest.yml -``` - -### Profile - -``` -./ -├── .env -├── docker-compose.yml -└── profile.yml -``` - -`.env` contains a list of environment variables used in the Docker Compose file. To know more about environment variables substitution in a Docker Compose file follow [this link](https://docs.docker.com/compose/environment-variables/set-environment-variables/#substitute-with-an-env-file). - -`docker-compose.yml` is a standard Docker Compose file declaring all the services, volumes, networks, etc. required for the AVS Node setup. - -`profile.yml` is the file that contains options to configure the profile. - -## Tap structure - -The Tap should contain a `README.md`, and a `pkg` folder with the contents described [above](#structure). Optionally, a `checksum.txt` file can be provided. The following directory structure can be used as reference: - -``` -./ -├── pkg/ -│ ├── mainnet/ -│ │ ├── .env -│ │ ├── docker-compose.yml -│ │ └── profile.yml -│ ├── goerli/ -│ │ ├── .env -│ │ ├── docker-compose.yml -│ │ └── profile.yml -│ └── manifest.yml -├── checksum.txt -└── README.md -``` - -### Checksum - -Calculating a checksum of the package is important to ensure the integrity and authenticity of the data being transferred or stored. A checksum is a value calculated from the content of the package, and can be used to verify that the package has not been altered or corrupted. - -:::note - -Providing a checksum is **optional**, but it's highly recommended to ensure the integrity of the package. - -::: - -:::caution - -The package's checksum **MUST** be calculated using the **SHA-256** hashing algorithm. - -::: - -The following script can be used to calculate the package checksum and generate the required `checksum.txt`: - - - - - ```bash - #!/bin/bash - - # Check if a package root argument is provided - if [ -z "$1" ]; then - echo "Usage: $0 " - exit 1 - fi - - # Set the package root directory and the output file - package_root="$1" - output_file="checksum.txt" - - # Remove the output file if it exists - rm -f "$output_file" - - # Iterate through all files in the package, calculate their SHA-256 checksum, and save the result to the output file - find "$package_root" -type f -not -path "*/.git/*" -exec sha256sum {} \; | sort -k 2 > "$output_file" - - # Print the final checksum of the output file - sha256sum "$output_file" - ``` - - Save this script as `calculate_checksum.sh` in any directory, give it executable permissions with `chmod +x calculate_checksum.sh`, and run it with `./calculate_checksum.sh /path/to/package_root` providing the package root directory path as an argument. The output will be a file called `checksum.txt` containing the checksums of all files within the package, sorted by file path. The final checksum of the `checksum.txt` file will be printed to the console. - - - - - ```shell - # Set the package root directory and the output file - $packageRoot = ".\" - $outputFile = "checksum.txt" - - # Remove the output file if it exists - if (Test-Path $outputFile) { - Remove-Item $outputFile - } - - # Iterate through all files in the package, calculate their SHA-256 checksum, and save the result to the output file - Get-ChildItem -Path $packageRoot -Recurse -File -Exclude ".git" | - ForEach-Object { - $hash = (Get-FileHash -Path $_.FullName -Algorithm SHA256).Hash.ToLower() - Add-Content -Path $outputFile -Value "$hash *$($_.FullName)" - } - - # Sort the output file by file path - (Get-Content $outputFile) | Sort-Object | Set-Content $outputFile - - # Print the final checksum of the output file - (Get-FileHash -Path $outputFile -Algorithm SHA256).Hash.ToLower() - ``` - - Save this script as `calculate_checksum.ps1` in any directory, and run it with `powershell -ExecutionPolicy Bypass -File .\calculate_checksum.ps1 "C:\path\to\package_root"` providing the package root directory path as an argument. The output will be a file called `checksum.txt` containing the checksum of all files within the package, sorted by file path. The final checksum of the `checksum.txt` file will be printed to the console. - - - - -#### Publishing the checksum - -In addition to including the `checksum.txt` file within the package uploaded to the tap repository, it is recommended that the checksum of the `checksum.txt` file be published on the release page, download page, or within the README. This enables users to calculate the package checksum, verify its consistency with the `checksum.txt` file in the package, and compare it to the published checksum. - -Furthermore, ongoing discussions are aimed at developing a method for publishing the checksum on-chain, with the intention of enhancing the security and robustness of the process. diff --git a/docs/docs/spec/packaging/profiles.md b/docs/docs/spec/packaging/profiles.md deleted file mode 100644 index 55b320b9..00000000 --- a/docs/docs/spec/packaging/profiles.md +++ /dev/null @@ -1,531 +0,0 @@ ---- -sidebar_position: 3 -id: profiles ---- - -# Profile file - -The configuration/profile file should be in YAML format and contain information about the AVS Node profile and its options. Options are any argument, flag, configuration value, or environment variable of any services within the AVS Node `docker-compose.yml` whose value might be required from the user input. - -The file’s name **MUST** be `profile.yml`. - -The `docker-compose.yml` is designed for a given setup of a given AVS Node version, and may have hardcoded values or settings, either in the `docker-compose.yml` or in the form of environment variables in a `.env` file with values. Settings could also be declared in the profile file in the `options` section, considering that an option is a flag mapping to an environment variable in the `docker-compose.yml` file. - -The [AVS setup wizard tool](/docs/category/avs-setup-wizard) would use each option or setting in the profile file to get this information from the user via prompts, arguments, or CLI flags. In case of an upgrade, values of unchanged settings can be used in the new version, and values for new settings would have to be requested by the user. - -Because values for settings could be declared in more than one place, we need to define some precedence rules, which are (from highest to lowest): - -1. The value set with a CLI flag or through a prompt because the option is in the package profile -2. The default value in the package profile if it is defined and is not set with the CLI -3. Value hardcoded in the `.env` provided in the package by the AVS developer - -## Profile file specification - -### Profile file - -```yaml -# Hardware Requirements overrides that will replace requirements from the manifest file for this profile -hardware_requirements_overrides: - -# Plugin overrides that will replace plugin from the manifest file for this profile -plugin_overrides: - -# List of options the user can set or use default values if defined in the