From 83eb95833fda728c5a4f69b308e3f3c5bef72404 Mon Sep 17 00:00:00 2001 From: Vojdan Kjorveziroski <vojdan.kjorveziroski@finki.ukim.mk> Date: Mon, 3 Jun 2024 18:00:59 +0200 Subject: [PATCH] Update the self-hosting guides with the new name --- docs/self-hosted-nmaas/install-guide.md | 48 +++++++++---------- docs/self-hosted-nmaas/introduction.md | 48 +++++++++---------- .../local-dev-environment/appendix.md | 10 ++-- .../local-dev-environment/introduction.md | 6 +-- .../p1_local-kubernetes-cluster.md | 20 ++++---- .../p2_installing-nmaas.md | 24 +++++----- .../p3_demo-network-environment.md | 6 +-- .../p4_monitoring-demo-network-environment.md | 24 +++++----- .../p5_adding_custom_app.md | 38 +++++++-------- 9 files changed, 112 insertions(+), 112 deletions(-) diff --git a/docs/self-hosted-nmaas/install-guide.md b/docs/self-hosted-nmaas/install-guide.md index 575ac15..ed9e894 100644 --- a/docs/self-hosted-nmaas/install-guide.md +++ b/docs/self-hosted-nmaas/install-guide.md @@ -1,21 +1,21 @@ -# NMaaS Installation Guide +# nmaas Installation Guide ## Requirements -To install NMaaS into an existing Kubernetes cluster, the following requirements must be met: +To install nmaas into an existing Kubernetes cluster, the following requirements must be met: - Kubernetes version `>=1.16` - Helm v3 support in the Kubernetes cluster - Existing ingress controller, preferably with a default TLS certificate set (more information available below) - An integration with an external load-balancer or MetalLB for bare-metal deployments, so that IPs can be assigned to `LoadBalancer` services. -## NMaaS Components +## nmaas Components -NMaaS is comprised of multiple components, and a brief description for each one is provided in the [self-hosting introduction](./introduction.md) page. +nmaas is comprised of multiple components, and a brief description for each one is provided in the [self-hosting introduction](./introduction.md) page. ## Installation -The NMaaS installation is a two-step process - first an instance of GItLab must be deployed and configured, and then NMaaS itself. The two components cannot be deployed at the same time, since during the deployment process NMaaS requires a GitLab API key to be specified. +The nmaas installation is a two-step process - first an instance of GItLab must be deployed and configured, and then nmaas itself. The two components cannot be deployed at the same time, since during the deployment process nmaas requires a GitLab API key to be specified. ### GitLab Installation @@ -37,10 +37,10 @@ GitLab can be deployed using the [official Helm chart](https://docs.gitlab.com/r !!! success "GitLab Version" - `4.8.2` is the latest version of the GitLab chart that has been tested with the latest version of NMaaS. + `4.8.2` is the latest version of the GitLab chart that has been tested with the latest version of nmaas. -Bellow is a snippet of the mandatory parameters that must be specified during GitLab's deployment, so that it will be compatible with NMaaS. The complete list of supported value parameters is available in the [official GitLab Helm chart Git repository](https://gitlab.com/gitlab-org/charts/gitlab). +Bellow is a snippet of the mandatory parameters that must be specified during GitLab's deployment, so that it will be compatible with nmaas. The complete list of supported value parameters is available in the [official GitLab Helm chart Git repository](https://gitlab.com/gitlab-org/charts/gitlab). ```yaml title="gitlab-values.yaml" certmanager: @@ -145,7 +145,7 @@ Note that the built-in PostgreSQL chart that can be automatically deployed toget In case an external PostgreSQL instance will be used then the secret specified in `.Values.global.psql.password.secret` must be created automatically. Also, keep in mind the warning given above, if a regular PostgreSQL user is specified, the `btree` and `trgm` extensions must be enabled beforehand. !!! info "GitLab Email Sending" - NMaaS does not rely on email sending via GitLab, so both the email and smtp sections in the value files can be left with their default values - unconfigured. However, users are free to customize these sections according to their own environments. + nmaas does not rely on email sending via GitLab, so both the email and smtp sections in the value files can be left with their default values - unconfigured. However, users are free to customize these sections according to their own environments. Once all configuration parameters have been specified, GitLab can be installed using the following Helm v3 command: @@ -165,9 +165,9 @@ Once GitLab has been deployed, it can be accessed by navigating to `gitlab.<TLD> Note that after deployment, by default, anyone can register to your newly deployed GitLab instance. This can be configured by logging in as the root GitLab user. - Users are advised to determine whether public exposure of the GitLab web interface is needed at all. NMaaS' GitLab integration can work even if only public access to the GitLab SSH interface is provided, since repository cloning always relies on SSH as the transport protocol. + Users are advised to determine whether public exposure of the GitLab web interface is needed at all. nmaas' GitLab integration can work even if only public access to the GitLab SSH interface is provided, since repository cloning always relies on SSH as the transport protocol. -To create a GitLab API token that can be used by NMaaS, perform the following steps: +To create a GitLab API token that can be used by nmaas, perform the following steps: - Login to GitLab using the root account; - Click on the avatar image in the top right corner and select `Settings`; @@ -179,13 +179,13 @@ To create a GitLab API token that can be used by NMaaS, perform the following st GitLab supports SSH access to any created repositories. If you want to allow your users to clone the repositories where their application configuration is stored, then you will have to alter the GitLab Shell service, and change its type to LoadBalancer, so that a routable IP address will be assigned to it. -### NMaaS Installation +### nmaas Installation -The source code for the NMaaS Helm chart is publicly available on [nmaas-platform/nmaas-chart](https://gitlab.software.geant.org/nmaas/nmaas-chart). The `README.md` file provides details on all the customizable `value` parameters for a given chart version. +The source code for the nmaas Helm chart is publicly available on [nmaas-platform/nmaas-chart](https://gitlab.software.geant.org/nmaas/nmaas-chart). The `README.md` file provides details on all the customizable `value` parameters for a given chart version. -The following manual steps must be performed before deploying NMaaS: +The following manual steps must be performed before deploying nmaas: -- Creating a private/public SSH keypair so that NMaaS Platform can access NMaaS Helm: +- Creating a private/public SSH keypair so that nmaas Platform can access nmaas Helm: ```bash #!/bin/bash @@ -227,12 +227,12 @@ helm install -f values.yaml --namespace $NMAAS_NAMESPACE --version 1.0.0 nmaas n It is recommended to use `nmaas-system` as the namespace where NMaaS and all associated components (PostgreSQL, GitLab) will be deployed. -!!! warning "NMaaS Deployment Time" - Please allow at least 10 minutes for NMaaS to be fully deployed, depending on hardware configuration and resource utilization. +!!! warning "nmaas Deployment Time" + Please allow at least 10 minutes for nmaas to be fully deployed, depending on hardware configuration and resource utilization. #### Verifying the Installation -You can verify that NMaaS has been successfully deployed by navigating to its ingress URL from your browser, logging in as the admin user and selecting `Settings -> Monitoring`. From this location, you can execute checks for all the required components of NMaaS. A fully functional installation should return a successful response for all monitors. +You can verify that nmaas has been successfully deployed by navigating to its ingress URL from your browser, logging in as the admin user and selecting `Settings -> Monitoring`. From this location, you can execute checks for all the required components of nmaas. A fully functional installation should return a successful response for all monitors. ## Administrator Information @@ -240,10 +240,10 @@ For more detailed instructions, refer to the [Domain Admin Guide](../guides/doma ### Creating New Domains -Creating a new customer domain within NMaaS is a two-step process: +Creating a new customer domain within nmaas is a two-step process: -1. First, the new domain should be added from the NMaaS web interface. The following steps should be performed. - - Login to the NMaaS Portal as the administrator user (the default administrator username is `admin` and the desired password is passed as a installation parameter); +1. First, the new domain should be added from the nmaas web interface. The following steps should be performed. + - Login to the nmaas Portal as the administrator user (the default administrator username is `admin` and the desired password is passed as a installation parameter); - Navigate to `Settings -> Domains`; - Click the `Add` button and enter the required parameters specific to the newly created domain: - `Name` - full name of given domain (e.g. `Test Domain`) @@ -251,7 +251,7 @@ Creating a new customer domain within NMaaS is a two-step process: - `Kubernetes namespace` *(Optional)* - a namespace dedicated for this domain to be created in the next step - `Kubernetes storage class` *(Optional)* - a specific storage class to be used for persistent volumes created in this domain (typically should be left blank) - `Kubernetes ingress class` *(Optional)* - a ingress class supported by the ingress controller deployed for this domain (should be left blank if a single common controller supports all the domains) - - `External service domain` - a base URL for accessing all applications deployed in this domain (typically should contain the Codename and the URL of NMaaS itself, e.g. `testdom.nmaas.example.com`) + - `External service domain` - a base URL for accessing all applications deployed in this domain (typically should contain the Codename and the URL of nmaas itself, e.g. `testdom.nmaas.example.com`) - `DCN deployment type` - by default should be set to `Manual` - `DCN status` - by default should be set to `Configured` - `Customer networks` *(to be removed)* - list of network prefixes to which applications deployed in this domain should have access (thought this parameter is currently mandatory it is not used for any automated actions so any initial values can be provided) @@ -286,8 +286,8 @@ Creating a new customer domain within NMaaS is a two-step process: ## Additional Documentation -An online user guide is available at [NMaaS User Guide](../guides/user-guide.md) page. +An online user guide is available at [nmaas User Guide](../guides/user-guide.md) page. -Information about the NMaaS applications deployment and configuration process and the NMaaS portfolio is available on the [NMaaS Tools](../nmaas-applications/general-app-deployment.md) page. +Information about the nmaas applications deployment and configuration process and the nmaas portfolio is available on the [nmaas Tools](../nmaas-applications/general-app-deployment.md) page. -In case of any questions please contact the NMaaS Team at [nmaas@lists.geant.org](mailto:nmaas@lists.geant.org). \ No newline at end of file +In case of any questions please contact the nmaas Team at [nmaas@lists.geant.org](mailto:nmaas@lists.geant.org). \ No newline at end of file diff --git a/docs/self-hosted-nmaas/introduction.md b/docs/self-hosted-nmaas/introduction.md index 4777fe2..3f4f659 100644 --- a/docs/self-hosted-nmaas/introduction.md +++ b/docs/self-hosted-nmaas/introduction.md @@ -1,52 +1,52 @@ # Introduction -Interested users have the option of self-hosting the NMaaS software on their own infrastructure. Depending on the environment, two guides are available: +Interested users have the option of self-hosting the nmaas software on their own infrastructure. Depending on the environment, two guides are available: -- The [production installation guide](./install-guide.md) which provides instructions on installing NMaaS on a full-fledged Kubernetes cluster involving multiple cluster nodes. -- The [local installation guide](./local-dev-environment/introduction.md) which provides instructions on installing NMaaS for evaluation purposes in smaller environments, consisting even of a single Kubernetes node. +- The [production installation guide](./install-guide.md) which provides instructions on installing nmaas on a full-fledged Kubernetes cluster involving multiple cluster nodes. +- The [local installation guide](./local-dev-environment/introduction.md) which provides instructions on installing nmaas for evaluation purposes in smaller environments, consisting even of a single Kubernetes node. -Note that apart from the infrastructure aspects, both guides share similarities when it comes to the actual NMaaS deployment, and can be consulted in parallel. +Note that apart from the infrastructure aspects, both guides share similarities when it comes to the actual nmaas deployment, and can be consulted in parallel. -## NMaaS Components +## nmaas Components -NMaaS' architecture is made up of three primary components and three helper components. +nmaas' architecture is made up of three primary components and three helper components. -The primary components have all been developed within the GEANT project and these are: the NMaaS Portal, the NMaas Platform, and the NMaaS Janitor. +The primary components have all been developed within the GÉANT project and these are: the nmaas Portal, the nmaas Platform, and the nmaas Janitor. -The helper components are represented as popular open-source software which has been packaged as Docker containers. These include: NMaaS Helm, NMaaS Postfix, and NMaaS Service Provider (SP). +The helper components are represented as popular open-source software which has been packaged as Docker containers. These include: nmaas Helm, nmaas Postfix, and nmaas Service Provider (SP). More details about the role that each of these components play are provided in the subsections below. -### NMaaS Platform +### nmaas Platform -NMaaS Platform is the central NMaaS component, exposing a REST API consumed by the NMaaS Portal. It stores the application catalog, the users, as well as information about any deployed applications. Upon a new request for an application deployment, it connects to the NMaaS Helm component and executes the necessary Helm command via an SSH connection. It also communicates with a self-hosted instance of GitLab, in order to provision boilerplate configuration files for the deployed application instances by the users, allowing them to make any additional configuration changes exclusively through Git. +nmaas Platform is the central nmaas component, exposing a REST API consumed by the nmaas Portal. It stores the application catalog, the users, as well as information about any deployed applications. Upon a new request for an application deployment, it connects to the nmaas Helm component and executes the necessary Helm command via an SSH connection. It also communicates with a self-hosted instance of GitLab, in order to provision boilerplate configuration files for the deployed application instances by the users, allowing them to make any additional configuration changes exclusively through Git. **External dependencies: PostgreSQL database, self-hosted GitLab instance** -### NMaaS Portal +### nmaas Portal -NMaaS Portal represents the front-end application of NMaaS that consumes the REST API offered by NMaaS Platform. NMaaS Portal is a Angular based application that is run in user's browser. +nmaas Portal represents the front-end application of nmaas that consumes the REST API offered by nmaas Platform. nmaas Portal is an Angular based application that is run in user's browser. -### NMaaS Janitor +### nmaas Janitor -The NMaaS Janitor is a helper service that interacts with the self-hosted GitLab API, and deploys the boilerplate configuration templates within the Kubernetes cluster. NMaaS Janitor is also used to retrieve the status of Kubernetes services and load balancer IPs assigned to them. For this reason it also needs privileges to use the Kubernetes API, albeit not as permissive as NMaaS Helm. +The nmaas Janitor is a helper service that interacts with the self-hosted GitLab API, and deploys the boilerplate configuration templates within the Kubernetes cluster. nmaas Janitor is also used to retrieve the status of Kubernetes services and load balancer IPs assigned to them. For this reason it also needs privileges to use the Kubernetes API, albeit not as permissive as nmaas Helm. -### NMaaS Helm +### nmaas Helm -NMaaS Helm interacts with the Kubernetes API of the underlying cluster where NMaaS is deployed, and manages it through the Helm v3 client. As a a result, it requires the cluster-admin Kubernetes role. Whenever a new application is deployed, the NMaaS Platform opens an SSH connection to NMaaS Helm and executes the required Helm command. +nmaas Helm interacts with the Kubernetes API of the underlying cluster where nmaas is deployed, and manages it through the Helm v3 client. As a a result, it requires the cluster-admin Kubernetes role. Whenever a new application is deployed, the nmaas Platform opens an SSH connection to nmaas Helm and executes the required Helm command. -### NMaaS Postfix +### nmaas Postfix -NMaaS Postfix is an in-cluster mail server that is used by any deployed applications to send emails to external destinations. It does not require any authentication before sending emails, and it can either be configured as a standalone mail server, or it can use a smart host, routing all outgoing emails through some other email server (e.g. Gmail). +nmaas Postfix is an in-cluster mail server that is used by any deployed applications to send emails to external destinations. It does not require any authentication before sending emails, and it can either be configured as a standalone mail server, or it can use a smart host, routing all outgoing emails through some other email server (e.g. Gmail). -!!! warning "NMaaS Postfix without a Smart Host" +!!! warning "nmaas Postfix without a Smart Host" - If NMaaS Postfix is not configured to use an external mail service for sending the emails, than most likely all outgoing emails will be marked as spam, and users will face delivery problems when sending alerts from their deployed applications. + If nmaas Postfix is not configured to use an external mail service for sending the emails, than most likely all outgoing emails will be marked as spam, and users will face delivery problems when sending alerts from their deployed applications. -### NMaaS Service Provider (SP) +### nmaas Service Provider (SP) -The NMaaS SP is an in-cluster SAML Proxy that allows for SSO user login based on SAML. The NMaaS SP component is composed of Apache HTTP server and a Shibboleth Service Provider (Shibboleth SP) software. NMaaS SP is initially configured to authenticate with eduGAIN as the federated Identify Provider but can be customized to work with any compliant IdP. +The nmaas SP is an in-cluster SAML Proxy that allows for SSO user login based on SAML. The nmaas SP component is composed of Apache HTTP server and a Shibboleth Service Provider (Shibboleth SP) software. nmaas SP is initially configured to authenticate with eduGAIN as the federated Identify Provider but can be customized to work with any compliant IdP. -!!! warning "NMaaS SP is still in a Testing Phase" +!!! warning "nmaas SP is still in a Testing Phase" - The in-cluster NMaaS SP was developed some time back but was never thoroughly tested. However NMaaS development team can provide guidelines on how to setup a NMaaS SAML Proxy on a dedicated VM. Such a setup is currently used for NMaaS production service. Nevertheless basic username and password based log in is available at all times. \ No newline at end of file + The in-cluster nmaas SP was developed some time back but was never thoroughly tested. However nmaas development team can provide guidelines on how to setup a nmaas SAML Proxy on a dedicated VM. Such a setup is currently used for nmaas production service. Nevertheless basic username and password based log in is available at all times. \ No newline at end of file diff --git a/docs/self-hosted-nmaas/local-dev-environment/appendix.md b/docs/self-hosted-nmaas/local-dev-environment/appendix.md index 1727e3c..eaf6caa 100644 --- a/docs/self-hosted-nmaas/local-dev-environment/appendix.md +++ b/docs/self-hosted-nmaas/local-dev-environment/appendix.md @@ -1,4 +1,4 @@ -# Appendix: Default Credentials for the NMaaS Development Virtual Machine +# Appendix: Default Credentials for the nmaas Development Virtual Machine !!! note Virtual Machine Download @@ -13,10 +13,10 @@ | Port for Telnet Access FreeRTR Instance #1 | 1124 | | Virtual Machine Username | nmaas | | Virtual Machine Password | nmaas | -| NMaaS URL | https://nmaas.10.99.99.150.nip.io | -| NMaaS Admin Username | admin | -| NMaaS Admin Password | saamn | -| NMaaS API Secret | saamn | +| nmaas URL | https://nmaas.10.99.99.150.nip.io | +| nmaas Admin Username | admin | +| nmaas Admin Password | saamn | +| nmaas API Secret | saamn | | GitLab URL | https://gitlab.nmaas.10.99.99.150.nip.io/users/sign_in | | GitLab Admin Username | root | | GitLab Admin Password | nmaasgitlab | diff --git a/docs/self-hosted-nmaas/local-dev-environment/introduction.md b/docs/self-hosted-nmaas/local-dev-environment/introduction.md index 0789fa7..1d24c3a 100644 --- a/docs/self-hosted-nmaas/local-dev-environment/introduction.md +++ b/docs/self-hosted-nmaas/local-dev-environment/introduction.md @@ -1,11 +1,11 @@ # Introduction to the Local Development Environment -Network management is an essential part of any production network, no matter its size. However, organizations often face staff shortages or lack the required resources to properly monitor their network. NMaaS (Network Management as a Service) is a GÉANT production service that allows effortless deployment of many open-source network monitoring tools on demand, with minimal initial configuration by the end users. Based on the Kubernetes container orchestrator, and deployable on private infrastructure as well, a dedicated NMaaS instance can be used as a central point for monitoring many distributed networks, by utilizing VPN tunnels. New applications can be added to the NMaaS catalogue at any time using Helm charts, an industry standard package manager for Kubernetes. NMaaS hides the operational complexity from end users who access the service through a web application from where they can manage and configure their existing application instances or deploy new ones. +Network management is an essential part of any production network, no matter its size. However, organizations often face staff shortages or lack the required resources to properly monitor their network. nmaas (Network Management as a Service) is a GÉANT production service that allows effortless deployment of many open-source network monitoring tools on demand, with minimal initial configuration by the end users. Based on the Kubernetes container orchestrator, and deployable on private infrastructure as well, a dedicated nmaas instance can be used as a central point for monitoring many distributed networks, by utilizing VPN tunnels. New applications can be added to the nmaas catalogue at any time using Helm charts, an industry standard package manager for Kubernetes. nmaas hides the operational complexity from end users who access the service through a web application from where they can manage and configure their existing application instances or deploy new ones. -Users can also evaluate NMaaS on their own infrastructure by either following this tutorial or by simply [downloading the already prepared virtual machine](https://drive1.demo.renater.fr/index.php/s/rp2awZ6sMnNFQwK). After downloading the virtual machine image, users are advised to follow [part 1](./p1_local-kubernetes-cluster.md) in order to set up the necessary VirtualBox NAT network which is required by the VM so that all of its components can run as expected, and the subnets described in the [Appendix](./appendix.md) remain unchanged. +Users can also evaluate nmaas on their own infrastructure by either following this tutorial or by simply [downloading the already prepared virtual machine](https://drive1.demo.renater.fr/index.php/s/rp2awZ6sMnNFQwK). After downloading the virtual machine image, users are advised to follow [part 1](./p1_local-kubernetes-cluster.md) in order to set up the necessary VirtualBox NAT network which is required by the VM so that all of its components can run as expected, and the subnets described in the [Appendix](./appendix.md) remain unchanged. By the end of this 5 part tutorial, users should have an exact replica of the setup done within the virtual machine. -This tutorial begins with [part 1](./p1_local-kubernetes-cluster.md) where a local Kubernetes cluster is initialized allowing users to choose between two lightweight Kubernetes distributions - MicroK8s or K3s. It then proceeds with [part 2](./p2_installing-nmaas.md) where the NMaaS installation procedure is explained, along with all required dependencies. In [part 3](./p3_demo-network-environment.md), a simple method is described for setting up virtualized demo networking devices that can later be used as monitoring targets for the applications deployed by NMaaS. The process of deploying such monitoring applications from the list of supported applications in the NMaaS catalog is described in [part 4](./p4_monitoring-demo-network-environment.md). The tutorial is concluded with [part 5](./p5_adding_custom_app.md), allowing advanced users to add their own custom applications to the NMaaS catalog, thus making it available to all potential users of their NMaaS instance. +This tutorial begins with [part 1](./p1_local-kubernetes-cluster.md) where a local Kubernetes cluster is initialized allowing users to choose between two lightweight Kubernetes distributions - MicroK8s or K3s. It then proceeds with [part 2](./p2_installing-nmaas.md) where the nmaas installation procedure is explained, along with all required dependencies. In [part 3](./p3_demo-network-environment.md), a simple method is described for setting up virtualized demo networking devices that can later be used as monitoring targets for the applications deployed by nmaas. The process of deploying such monitoring applications from the list of supported applications in the nmaas catalog is described in [part 4](./p4_monitoring-demo-network-environment.md). The tutorial is concluded with [part 5](./p5_adding_custom_app.md), allowing advanced users to add their own custom applications to the nmaas catalog, thus making it available to all potential users of their nmaas instance. For users who choose to download the already prepared virtual machine and avoid the whole setup process, the [Appendix](./appendix.md) gives an overview of all the credentials that have been used. \ No newline at end of file diff --git a/docs/self-hosted-nmaas/local-dev-environment/p1_local-kubernetes-cluster.md b/docs/self-hosted-nmaas/local-dev-environment/p1_local-kubernetes-cluster.md index c9e75ba..b651307 100644 --- a/docs/self-hosted-nmaas/local-dev-environment/p1_local-kubernetes-cluster.md +++ b/docs/self-hosted-nmaas/local-dev-environment/p1_local-kubernetes-cluster.md @@ -1,6 +1,6 @@ # Part 1: Deploying a Local Kubernetes Cluster -This tutorial will assume that NMaaS is installed in a virtual machine that is completely isolated from any production environment. However, the discussed steps are applicable to bare-metal hardware as well, once the correct network strategy has been identified by the system administrator. +This tutorial will assume that nmaas is installed in a virtual machine that is completely isolated from any production environment. However, the discussed steps are applicable to bare-metal hardware as well, once the correct network strategy has been identified by the system administrator. ## Virtual Machine Prerequisites @@ -13,12 +13,12 @@ This tutorial will assume that NMaaS is installed in a virtual machine that is c Although we will focus on VirtualBox, any virtualization software can be used, depending on the user's preference. Virtualbox 6 is an open-source virtualization software which can be downloaded for free from the [official website](https://www.virtualbox.org/wiki/Downloads). -After installation, additional network configuration needs to be done before a Kubernetes cluster can be set up. The following network configuration creates a completely isolated network environment from the production network. NMaaS will only be accessible from the host operating system where the virtual machine is deployed. +After installation, additional network configuration needs to be done before a Kubernetes cluster can be set up. The following network configuration creates a completely isolated network environment from the production network. nmaas will only be accessible from the host operating system where the virtual machine is deployed. Our virtual machine will need three network interfaces in total: - 3 NAT type network adapters (from the same NAT network) which are created manually in Virtualbox (one for Kubernetes, two for freeRTR) -- **Optional:** 1 Host-only type network adapter which is also created manually in Virtualbox - for accessing the NAT network from the host system. Using this approach, the NMaaS instance deployed inside the virtual machine will be made accessible by adding a custom route on the host operating system towards the NAT network, traversing the host-only interfaces. +- **Optional:** 1 Host-only type network adapter which is also created manually in Virtualbox - for accessing the NAT network from the host system. Using this approach, the nmaas instance deployed inside the virtual machine will be made accessible by adding a custom route on the host operating system towards the NAT network, traversing the host-only interfaces. DHCP should not be enabled for the second or third NAT interfaces, but DHCP should be enabled for the first NAT interface. If an optional host interface has been added, DHCP should be enabled on it as well. @@ -34,11 +34,11 @@ Detailed description of the required configuration steps is given below.  -- If the pre-prepared NMaaS VirtualBox image is used, make sure to select the exact same Network CIDR (10.99.99.0/24) since all NMaaS components have already been installed and expect addresses in the 10.99.99.0/24 range. +- If the pre-prepared nmaas VirtualBox image is used, make sure to select the exact same Network CIDR (10.99.99.0/24) since all nmaas components have already been installed and expect addresses in the 10.99.99.0/24 range. ### Optional: Creating a New Host-Only Network in Virtualbox -If the NMaaS installation needs to be accessible from other networks, one option is to add a Host-Only interface to the virtual machine that will act as a transit between the outside networks and the internal VirtualBox NAT network configured in the previous step. +If the nmaas installation needs to be accessible from other networks, one option is to add a Host-Only interface to the virtual machine that will act as a transit between the outside networks and the internal VirtualBox NAT network configured in the previous step. - Navigate to `File -> Host Network Manager` and click on the green `Create` Button. @@ -52,7 +52,7 @@ If the NMaaS installation needs to be accessible from other networks, one option Create a regular virtual machine in VirtualBox, using the latest Ubuntu 20.04 ISO. The following parameters need to be altered: -- Allocate sufficient memory to the virtual machine. 12GB is the minimum amount which will support a complete NMaaS installation, along with the possibility for deploying additional applications via the catalog. +- Allocate sufficient memory to the virtual machine. 12GB is the minimum amount which will support a complete nmaas installation, along with the possibility for deploying additional applications via the catalog. - Allocate sufficient number of CPU cores, depending on the performance of your system. - In the `Network` configuration tab, add three adapters: - Adapter 1: NAT Network (Select the network created [previously](./p1_local-kubernetes-cluster.md#creating-a-new-nat-network-in-virtualbox)) @@ -238,7 +238,7 @@ Once the assigned IP to the LoadBalancer Service has been acquired by executing ##### Helm -Helm is a package manager for Kubernetes allowing seamless installation of complex application. NMaaS and all of its dependencies have also been packaged as Helm charts, thus easing their deployment process. +Helm is a package manager for Kubernetes allowing seamless installation of complex application. nmaas and all of its dependencies have also been packaged as Helm charts, thus easing their deployment process. ```bash microk8s enable helm3 @@ -255,7 +255,7 @@ microk8s helm3 list --all-namespaces !!! danger "Helm Version" - Unfortunately, the Helm version installed in this manner, as an official MicroK8s addon is too old. A newer version, if needed, can be installed by following the instructions available below. **Please note that the GitLab chart, which is a dependency of NMaaS requires a newer Helm version than the one installed as a MicroK8s addon.** + Unfortunately, the Helm version installed in this manner, as an official MicroK8s addon is too old. A newer version, if needed, can be installed by following the instructions available below. **Please note that the GitLab chart, which is a dependency of nmaas requires a newer Helm version than the one installed as a MicroK8s addon.** ###### Installing a Newer Helm Version @@ -428,7 +428,7 @@ To install Helm, we need to first download the latest binary for our architectur ##### Ingress Nginx -The last application that needs to be installed before we can move on to installing the NMaaS components is Ingress Nginx. Since we have already configured Helm, the Ingress Nginx installation is simple. +The last application that needs to be installed before we can move on to installing the nmaas components is Ingress Nginx. Since we have already configured Helm, the Ingress Nginx installation is simple. - Customize the values.yaml file according to the local environment: @@ -460,7 +460,7 @@ The last application that needs to be installed before we can move on to install helm install -f ingress-values.yaml --namespace nmaas-system nmaas-ingress ingress-nginx/ingress-nginx ``` - We have chosen to install `ingress-nginx` in the `nmaas-system` namespace, which will house all the other NMaaS components as well. + We have chosen to install `ingress-nginx` in the `nmaas-system` namespace, which will house all the other nmaas components as well. !!! danger "Note About Helm Errors" diff --git a/docs/self-hosted-nmaas/local-dev-environment/p2_installing-nmaas.md b/docs/self-hosted-nmaas/local-dev-environment/p2_installing-nmaas.md index 756d979..c343722 100644 --- a/docs/self-hosted-nmaas/local-dev-environment/p2_installing-nmaas.md +++ b/docs/self-hosted-nmaas/local-dev-environment/p2_installing-nmaas.md @@ -1,6 +1,6 @@ -# Part 2: Installing NMaaS +# Part 2: Installing nmaas -Once a working Kubernetes cluster has been deployed, we are ready to proceed to the next step - installing NMaaS. +Once a working Kubernetes cluster has been deployed, we are ready to proceed to the next step - installing nmaas. All the necessary components will be installed in a single namespace – `nmaas-system`. If this namespace has not been created so far, execute: @@ -10,7 +10,7 @@ kubectl create namespace nmaas-system ## GitLab Installation -The first NMaaS dependency that we will set up is GitLab, a self-hosted web based Git repository hosting service. Many applications that are deployed by NMaaS users store their configuration data in a Git repository, allowing easier editing, and version management. +The first nmaas dependency that we will set up is GitLab, a self-hosted web based Git repository hosting service. Many applications that are deployed by nmaas users store their configuration data in a Git repository, allowing easier editing, and version management. GitLab has an official Helm chart, and we will use it to create a basic GitLab installation locally. Some parameters must be customized in the values.yaml file before deployment: @@ -124,14 +124,14 @@ Once GitLab has been deployed, it should be possible to navigate to the login pa - `Allow requests to the local network from web hooks and services` = checked - `Allow requests to the local network from system hooks` = checked -The final step before installing NMaaS itself is to generate a GitLab personal access token which will allow NMaaS to connect to the GitLab API. This can be done from the User Profile page: +The final step before installing nmaas itself is to generate a GitLab personal access token which will allow nmaas to connect to the GitLab API. This can be done from the User Profile page: - Click on the user avatar in the right-hand corner of the screen, Edit Profile. Select Access Tokens from the left-hand navigation menu. Give a new name for the authentication token, as well as an optional expiry date. Check all scopes. - Store the token until the next section, where we will create a new secret containing it. -## NMaaS Installation +## nmaas Installation -The final step is to install NMaaS. NMaaS uses SSH communication to connect between components, so we need to create an SSH key pair and store it in a Kubernetes secret. This can be done by executing the following commands: +The final step is to install nmaas. nmaas uses SSH communication to connect between components, so we need to create an SSH key pair and store it in a Kubernetes secret. This can be done by executing the following commands: ```bash #!/bin/bash @@ -145,12 +145,12 @@ kubectl create secret generic nmaas-helm-key-private -n <NMAAS_NAMESPACE> --from kubectl create secret generic nmaas-helm-key-public -n <NMAAS_NAMESPACE> --from-file=helm=$tmpdir/key.pub ``` -A few parameters need to be customized in the values.yaml file, to reflect the environment where NMaaS is deployed. +A few parameters need to be customized in the values.yaml file, to reflect the environment where nmaas is deployed. - `global.wildcardCertificateName` – the name of the secret containing the TLS certificate to be used to secure the HTTP communication -- `global.nmaasDomain` – the hostname where NMaaS will be accessible. +- `global.nmaasDomain` – the hostname where nmaas will be accessible. - `platform.properties.adminEmail` – the email address which will receive various notifications such as new user sign-up, deployment errors, new application versions... -- `platform.adminPassword.literal` – the password used to login as the admin user in the NMaaS Portal. +- `platform.adminPassword.literal` – the password used to login as the admin user in the nmaas Portal. - `platform.properties.k8s.ingress.certificate.issuerOrWildcardName` – the name of the wilcard certificate to be used for customer deployed applications, or the name of the cert-manager issuer to use if certificates are issued ad-hoc. - `platform.properties.k8s.ingress.controller.ingressClass` – the ingress class to be used for deployed applications. Should be set to nginx in the case of K3s and public in the case of MicroK8s. - `platform.properties.k8s.ingress.controller.publicIngressClass` – the ingress class to be used for applications where the users have explicitly selected to enable public access (e.g. without a VPN). Since this is a local deployment, the value of this parameter should equal the value set in `platform.properties.k8s.ingress.controller.ingressClass`. @@ -205,14 +205,14 @@ janitor: gitlabApiUrl: http://nmaas-gitlab-webservice-default:8181/api/v4 ``` -Once the values.yaml file has been customized, NMaaS can be deployed by executing: +Once the values.yaml file has been customized, nmaas can be deployed by executing: ```bash helm repo add nmaas https://artifactory.software.geant.org/artifactory/nmaas-helm helm install -f nmaas-values.yaml --namespace nmaas-system nmaas --version 1.1.2 nmaas/nmaas ``` -NMaaS also requires an the stakater autoreloader component, which can simply be installed using the commands below. This component takes care of restarting the affected pods whenever a configuration change is submitted via GitLab. +nmaas also requires an the stakater autoreloader component, which can simply be installed using the commands below. This component takes care of restarting the affected pods whenever a configuration change is submitted via GitLab. ```bash helm repo add stakater https://stakater.github.io/stakater-charts @@ -222,4 +222,4 @@ helm install config-reload --namespace nmaas-system stakater/reloader After the installation, login as the `admin` user should be possible with the configured password. - \ No newline at end of file + \ No newline at end of file diff --git a/docs/self-hosted-nmaas/local-dev-environment/p3_demo-network-environment.md b/docs/self-hosted-nmaas/local-dev-environment/p3_demo-network-environment.md index 366348f..98f1a66 100644 --- a/docs/self-hosted-nmaas/local-dev-environment/p3_demo-network-environment.md +++ b/docs/self-hosted-nmaas/local-dev-environment/p3_demo-network-environment.md @@ -4,7 +4,7 @@ These instructions are heavily based on the excellent blog posts and FreeRTR Docs written by [Fréderic Loui](https://twitter.com/FredericLoui) and the RARE team. -If there are existing network elements ready to be monitored by NMaaS applications, then this part can be completely skipped. +If there are existing network elements ready to be monitored by nmaas applications, then this part can be completely skipped. ## Configuring VirtualBox @@ -163,7 +163,7 @@ The addition of new interfaces can be easily accomplished from the VirtualBox VM - Adding a default route: `ipv4 route v1 0.0.0.0 0.0.0.0 192.168.1.1` - Configuring a static IP: `ipv4 addr 192.168.1.17 255.255.255.0` - - The sensor directives need to be left as they are, since they configure the Prometheus Exporter which will be scrapped using an NMaaS hosted Prometheus instance which we will deploy in the next part. + - The sensor directives need to be left as they are, since they configure the Prometheus Exporter which will be scrapped using an nmaas hosted Prometheus instance which we will deploy in the next part. 5. As a last step before starting the FreeRTR process, we need to bring up our second interface and disable hardware offloading: @@ -282,4 +282,4 @@ If automatic startup of the virtual devices is desired, a SystemD service unit c systemctl enable --now pcap-freertr-r1 ``` -We are now ready to configure monitoring and configuration backup of our virtual router using tools from the NMaaS catalog. \ No newline at end of file +We are now ready to configure monitoring and configuration backup of our virtual router using tools from the nmaas catalog. \ No newline at end of file diff --git a/docs/self-hosted-nmaas/local-dev-environment/p4_monitoring-demo-network-environment.md b/docs/self-hosted-nmaas/local-dev-environment/p4_monitoring-demo-network-environment.md index 13aaa90..c8cf9b1 100644 --- a/docs/self-hosted-nmaas/local-dev-environment/p4_monitoring-demo-network-environment.md +++ b/docs/self-hosted-nmaas/local-dev-environment/p4_monitoring-demo-network-environment.md @@ -1,10 +1,10 @@ -# Part 4: Monitoring the Demo Network Environment with NMaaS +# Part 4: Monitoring the Demo Network Environment with nmaas -## Registering a new Local NMaaS User +## Registering a new Local nmaas User -Registering a new local NMaaS user can be done from the NMaaS homepage. +Registering a new local nmaas user can be done from the nmaas homepage. - + Once all of the required fields (denoted by a red *) are filled, and the privacy policy accepted, the registration form can be submitted. @@ -12,7 +12,7 @@ After submission, an administrator approval is required before being able to log ### Approving the New User (as Admin) and Creating a New Domain -To approve a newly registered user, login as the NMaaS admin, and navigate to `Settings -> Users` from the right-hand side navigation menu. Hover over the cog next to the new user and select `Enable`. +To approve a newly registered user, login as the nmaas admin, and navigate to `Settings -> Users` from the right-hand side navigation menu. Hover over the cog next to the new user and select `Enable`.  @@ -28,7 +28,7 @@ Once enabled, the user should be made part of an existing domain. Since we curre ``` - For a local deployment, leave the Kubernetes storage class field empty, and set Kubernetes Ingress class to the ingress class available in the cluster (public for MicroK8s, nginx for K3s) -- As External service domain set the domain codename, suffixed by the NMaaS URL. For example, if the domain codename is demo, then External service domain should be set to `demo.nmaas.<INGRESS_LB_IP>.nip.io`. +- As External service domain set the domain codename, suffixed by the nmaas URL. For example, if the domain codename is demo, then External service domain should be set to `demo.nmaas.<INGRESS_LB_IP>.nip.io`. - Set the DCN deployment type to `Manual` and tick `DCN Configured`. - Set a dummy customer network, for example `127.0.0.1/24`. @@ -92,18 +92,18 @@ By now we have configured Prometheus to monitor the devices in our environment, Grafana is an open-source application that can generate graphs from different data sources, including Prometheus. -To deploy Grafana in an NMaaS environment, the same general steps can be used as before: +To deploy Grafana in an nmaas environment, the same general steps can be used as before: - subscribing to the Grafana application from the Applications page - creating a new instance from the Subscriptions page  -The configuration wizard that becomes available once the deployment enters the Deployed phase is different in the case of Grafana. Apart from specifying the Grafana username and password that can be used for accessing the web interface, users have the option of directly choosing an existing Prometheus instance that has been deployed within their NMaaS domain, and adding it as a data source to Grafana. This can be accomplished by ticking the `Connect to existing Prometheus instance` checkbox, and selecting the `NMaaS Prometheus Instance` radio button. +The configuration wizard that becomes available once the deployment enters the Deployed phase is different in the case of Grafana. Apart from specifying the Grafana username and password that can be used for accessing the web interface, users have the option of directly choosing an existing Prometheus instance that has been deployed within their nmaas domain, and adding it as a data source to Grafana. This can be accomplished by ticking the `Connect to existing Prometheus instance` checkbox, and selecting the `nmaas Prometheus Instance` radio button.  -Of course, a Grafana instance hosted on NMaaS can be used for connecting to external data sources as well. In this case, the checkbox `Connect to existing Prometheus instance` can simply be left unchecked. +Of course, a Grafana instance hosted on nmaas can be used for connecting to external data sources as well. In this case, the checkbox `Connect to existing Prometheus instance` can simply be left unchecked. Once the application is deployed, it can be accessed by selecting the `Actions -> Access` button. After login, users can verify that the previously deployed Prometheus instance has been added as a Data Source by selecting the cog icon on the left hand side and choosing `Data Sources`. @@ -134,7 +134,7 @@ After importing the dashboard, a redirect is immediately issued, and the defined Oxidized is an open-source application that is capable of fetching the configuration of remote devices and if enabled, version it using an internal or external Git repository. -In our demo scenario, we will use Oxidized to periodically fetch the configuration from the available network elements. To do so, we must first deploy Oxidized in our NMaaS domain. +In our demo scenario, we will use Oxidized to periodically fetch the configuration from the available network elements. To do so, we must first deploy Oxidized in our nmaas domain. The deployment steps for Oxidized are very similar to the other applications that have been deployed so far: @@ -297,11 +297,11 @@ The second column, the IP addresses, should be replaced with the IP addresses of The final step is to simply commit the changes that have been made. If this is the first time that Git is used, then the global Git `user.name` and `email` should be set: ```bash -git config --global user.name "NMaaS Demo" +git config --global user.name "nmaas Demo" git config --global user.email "nmaas_demo@example.com" ``` -Any value can be used for these parameters, they are not related to NMaaS. +Any value can be used for these parameters, they are not related to nmaas. The changes can be committed and pushed to the remote repository using: diff --git a/docs/self-hosted-nmaas/local-dev-environment/p5_adding_custom_app.md b/docs/self-hosted-nmaas/local-dev-environment/p5_adding_custom_app.md index 86d2ff6..1127843 100644 --- a/docs/self-hosted-nmaas/local-dev-environment/p5_adding_custom_app.md +++ b/docs/self-hosted-nmaas/local-dev-environment/p5_adding_custom_app.md @@ -1,12 +1,12 @@ -# Part 5: Adding a Custom Application to the NMaaS Catalog +# Part 5: Adding a Custom Application to the nmaas Catalog -Any application that has an existing Helm chart can be added to the NMaaS catalog. In this example we will use the popular uptime monitoring application - [UptimeKuma](https://github.com/louislam/uptime-kuma). +Any application that has an existing Helm chart can be added to the nmaas catalog. In this example we will use the popular uptime monitoring application - [UptimeKuma](https://github.com/louislam/uptime-kuma). -The agenda is to first create a regular Helm chart, without introducing any NMaaS dependencies, thus keeping it reusable across platforms. Then, we will add this Helm chart as a new application to the NMaaS catalog. +The agenda is to first create a regular Helm chart, without introducing any nmaas dependencies, thus keeping it reusable across platforms. Then, we will add this Helm chart as a new application to the nmaas catalog. ## Creating a Helm Chart -NMaaS does not mandate any requirements when creating Helm charts. If Helm best practices are followed, then there should not be any problem in integrating the application to the NMaaS catalog. +nmaas does not mandate any requirements when creating Helm charts. If Helm best practices are followed, then there should not be any problem in integrating the application to the nmaas catalog. The boilerplate code for a new Helm chart can be generated using the helm create command: @@ -254,19 +254,19 @@ persistence: existingClaim: "" ``` -Note that no NMaaS specific information has been used in the chart. The same chart can be used to create an instance of the uptime-kuma application on any Kubernetes cluster. +Note that no nmaas specific information has been used in the chart. The same chart can be used to create an instance of the uptime-kuma application on any Kubernetes cluster. Once the chart has been created, it should be uploaded to a Helm repository. There are many providers which allow hosting of Helm charts free of charge. -!!! note "Submitting an Application to the NMaaS catalog" +!!! note "Submitting an Application to the nmaas catalog" For more information, please have a look at our dedicated guide where a step-by-step explanation is provided on using GitHub for hosting and publishing Helm charts - [Adding a New Application](../../nmaas-applications/new-application.md). -## Adding a new Application to the NMaaS Catalog +## Adding a new Application to the nmaas Catalog -After the chart has been updated to a public Helm repository, the new application wizard can be used to add it to the NMaaS catalog. +After the chart has been updated to a public Helm repository, the new application wizard can be used to add it to the nmaas catalog. -- Login as the administrator user within the NMaaS portal and choose `Settings -> Applications`. +- Login as the administrator user within the nmaas portal and choose `Settings -> Applications`. - Click on the blue `Add` button in the top-left corner. - The new application wizard consists of 7 steps. These steps are: - General information @@ -283,7 +283,7 @@ In the sections that follow we elaborate further on each step. ### Step 1: General Information -The general information step provides a brief description of the process for adding a new application to the NMaaS catalog. +The general information step provides a brief description of the process for adding a new application to the nmaas catalog. Users are required only to tick the `I read the general instructions above checkbox before proceeding to the next step, Basic application information`. @@ -305,7 +305,7 @@ Before uploading any images, please ensure that you have the appropriate copyrig ### Step 4: Application Descriptions -NMaaS supports localization in multiple languages. By default the Application descriptions steps shows input fields for `Brief description` and `Full description` of the application in English. These fields should be used to provide a brief introduction for new users to the applications, explaining its features, as well as any default username or passwords that have been used and users are expected to change. +nmaas supports localization in multiple languages. By default the Application descriptions steps shows input fields for `Brief description` and `Full description` of the application in English. These fields should be used to provide a brief introduction for new users to the applications, explaining its features, as well as any default username or passwords that have been used and users are expected to change. Translation of the content can be provided for additional languages by choosing the `Select optional languages` dropdown in the bottom left corner. @@ -320,7 +320,7 @@ The deployment specification page contains common parameters that should be para The basic application information is consisted of the following fields: - **Chart name** – the name of the Helm chart that has been uploaded to a public repository. All instances created by end-users will actually be Releases of this chart. -- **Chart version** – the chart version to be used for creating new application instances. Note that NMaaS fully supports application versioning, and more than one application version can be active and available in the NMaaS catalog at a given point in time. Additional versions can be added once the application has been integrated into the catalog. +- **Chart version** – the chart version to be used for creating new application instances. Note that nmaas fully supports application versioning, and more than one application version can be active and available in the nmaas catalog at a given point in time. Additional versions can be added once the application has been integrated into the catalog. - **Helm Chart repository URL address** – the full URL to the Helm repository where the chart is hosted. - **Expose web user interface** – whether the application being added to the catalog exposes a web interface that should be reachable by users. In the case of UptimeKuma, this should be ticked. - **Allow SSH access** – whether the application being added to the catalog comes with a built-in SSH server through which the users can directly connect to the container where the application is running, e.g., for additional configuration. @@ -329,7 +329,7 @@ The basic application information is consisted of the following fields: #### Global Deploy Parameters -The global deploy parameters allow the administrator to pass some globally defined NMaaS variables to the Helm Release during its deployment. For example, many applications allow users to specify outbound SMTP servers which can be used for external email sending. Since NMaaS already has an SMTP component, any deployed application can simply use the configured and tested NMaaS email server. In this case, the system variables `SMTP_HOSTNAME`, `SMTP_PORT`, `SMTP_USERNAME`, `SMTP_PASSWORD` can be passed to arbitrary Helm value keys. +The global deploy parameters allow the administrator to pass some globally defined nmaas variables to the Helm Release during its deployment. For example, many applications allow users to specify outbound SMTP servers which can be used for external email sending. Since nmaas already has an SMTP component, any deployed application can simply use the configured and tested nmaas email server. In this case, the system variables `SMTP_HOSTNAME`, `SMTP_PORT`, `SMTP_USERNAME`, `SMTP_PASSWORD` can be passed to arbitrary Helm value keys. For example, the following configuration would pass the global `SMTP_HOSTNAME` deploy parameter as the `config.smtp.host` chart parameter whenever a new Release is created: @@ -350,11 +350,11 @@ In the case of UptimeKuma, we do not need to configure any global deploy paramet #### Static Global Deploy Parameters -Static global deploy parameters allow the application administrator to specify custom parameters that should be passed to the chart whenever a new Release is being created. Please note that this is different than `Global Deploy Parameters` which were used to pass an ***internal*** NMaaS parameter to each new Release. +Static global deploy parameters allow the application administrator to specify custom parameters that should be passed to the chart whenever a new Release is being created. Please note that this is different than `Global Deploy Parameters` which were used to pass an ***internal*** nmaas parameter to each new Release. In the case of static global deploy parameters, there is no limitation on what can be passed as a value. -Let's assume that our chart has a values.yaml parameter that enables or disables new user registration, and this parameter is set to enable by default. If we want to disable new user registrations for each new Release and do not want the NMaaS user to have an option to enable registrations, then we can simple disable this behavior using a static global deploy parameter. An example is given below. +Let's assume that our chart has a values.yaml parameter that enables or disables new user registration, and this parameter is set to enable by default. If we want to disable new user registrations for each new Release and do not want the nmaas user to have an option to enable registrations, then we can simple disable this behavior using a static global deploy parameter. An example is given below.  @@ -379,9 +379,9 @@ In the case of UptimeKuma, the following configuration is required: #### Access Methods -The Access Methods section allows the application administrator to customize the parameters related to external access. As previously, NMaaS parameters are mapped to the appropriate parameters exposed by the Chart's values.yaml file. +The Access Methods section allows the application administrator to customize the parameters related to external access. As previously, nmaas parameters are mapped to the appropriate parameters exposed by the Chart's values.yaml file. -Most of the parameters are self-explanatory, but some warrant additional attention. For example: the `INGRESS_CLASS` parameter will contain the ingress class that should be used for the newly deployed ingress object once the Helm Release is created. This is an essential information, since NMaaS supports per-domain ingress controllers. Without this information, the wrong ingress controller will most like be used for serving, or the application would not be accessible at all. +Most of the parameters are self-explanatory, but some warrant additional attention. For example: the `INGRESS_CLASS` parameter will contain the ingress class that should be used for the newly deployed ingress object once the Helm Release is created. This is an essential information, since nmaas supports per-domain ingress controllers. Without this information, the wrong ingress controller will most like be used for serving, or the application would not be accessible at all. In the case of UptimeKuma, the following configuration is required: @@ -393,7 +393,7 @@ In the Configuration Templates step the administrator can specify which chart pa  -Let's presume that the chart exposes a `global.notifications.certificateExpiry` parameter which customizes whether the application will send certificate expiry notifications for added monitors or not. We can allow the NMaaS users to customize this parameter in the following way. +Let's presume that the chart exposes a `global.notifications.certificateExpiry` parameter which customizes whether the application will send certificate expiry notifications for added monitors or not. We can allow the nmaas users to customize this parameter in the following way. - This parameter would best be modeled by a checkbox, so we drag-and-drop the checkbox component from the left hand side toolbar to the main canvas. - In the `Display` tab enter basic information about the new form field, such as its label, description, and optional tooltip that will be shown on hover. @@ -416,6 +416,6 @@ If no additional changes need to be made, the application can be submitted by cl ### Approving the Application -Before the application will be shown to all users of the NMaaS instance, it must be activated. This can be done from the Applications page by simply expanding the list of application versions, hovering on the cog button, selecting the `Change state` option and setting the state to `Active`. +Before the application will be shown to all users of the nmaas instance, it must be activated. This can be done from the Applications page by simply expanding the list of application versions, hovering on the cog button, selecting the `Change state` option and setting the state to `Active`.  \ No newline at end of file -- GitLab