GitOps

A submission declaration is essentially a dictionary that can be saved as either a JSON or YAML file. This means that consumers can manage and store their declarations in a Git repository. Utilizing Git offers several advantages. For instance, consumers can maintain a complete history of all changes made to their declarations. For each submission, they can create a Merge Request, allowing for the review and approval of any modifications.

Set Up Repository

Create a directory where you want to keep all files regarding your submission, and then create a git repository inside the repository.

Repository Structure

The following is an overview of the consumer's git repository structure:

git_root_directory/
  ├── .netorca/
  │   ├── config.yaml
  │   ├── <application_name>.yaml
  │   └── <application_name>.yaml
  └── .gitlab-ci.yml

config.yaml

This file contains the Team Metadata and the NetOrca base url. Here is an example of a config.yaml file:

---
netorca_global:
  base_url: https://api.netorca.io/v1
  metadata:
    budget_code: 12345
    team_name: alpha
    email: alpha@mail.com

In this file, netorca_global, base_url, metadata are the required keys. The team metadata is dictionary defined by the consumer. In the example above, it would be:

{
  "budget_code": 12345,
  "team_name": "alpha",
  "email": "alpha@mail.com"
}

<application_name>.yaml

In NetOrca, Service Items are defined within an Application. Consumers can define multiple application in one submission. Each application must be defined in <application_name>.yaml file.

Here is the template of each application yaml file:

---
<application_name>:
  metadata:
    key: value
  services:
    <service_1_name>:
      - name: <service_item_name>
        key: value
      - name: <service_item_name>
        key: value
    <service_2_name>:
      - name: <service_item_name>
        key: value
      - name: <service_item_name>
        key: value

Example

Considering the following services defined in NetOrca Catalog by Service Owners:

VM:
    name: str
    cpu: int
    ram: int
LoadBalancer:
    name: str
    algorithm: str

A full example of an application yaml file would be:

---
AwesomeApplication:
  metadata:
    application_ci: CI123456
    env: dev
  services:
    VM:
      - name: CoreVM1
        cpu: 4
        memory: 8
      - name: CoreVM2
        cpu: 2
        memory: 4
    LoadBalancer:
      - name: CoreLB1
        algorithm: round-robin

.gitlab-ci.yml

NetOrca offers a CI/CD script for both validation and submission. When this script is included in the consumer's repository, any push to the default branch (e.g., main or master) will automatically submit the declaration to NetOrca. For other branches, the declaration will only be sent to NetOrca for validation.

Below is the CI/CD script to be utilized in a GitLab repository:

stages:
  - validate
  - submit

image: python:3.10-buster
before_script:
  - pip install -q --upgrade pip
  - pip install -q netorca-sdk

validate:
  stage: validate
  variables:
    NETORCA_VALIDATE_ONLY: "True"
  script:
    - wget -q 'https://netautomate.gitlab.io/netorca_tools/cicd/dev/consumer_submission.py'
    - python consumer_submission.py
  rules:
    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH

submit:
  stage: submit
  variables:
    NETORCA_VALIDATE_ONLY: "False"
  script:
    - wget -q 'https://netautomate.gitlab.io/netorca_tools/cicd/dev/consumer_submission.py'
    - python consumer_submission.py
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

include:
  - template: 'Workflows/MergeRequest-Pipelines.gitlab-ci.yml'