Page Comparison

...

1. Summary

2. Components and useful links 

3. Main architecture

4. Release process

5. Create, update, publish a vagrant VM 

6. ARM Pipeline

7. Firebase

8. Current DevOps problems/issues

9. Ongoing projects

10. Build Process 

    Registry 

11. Registry

     

1. Summary

In most books DevOps is the bridge between Ops and Dev, it’s true in most cases but in magma our primary mission is to make sure magma is a project that is easily to build, test, deploy and improve. We have to make sure that the developer/contributor experience is on point. It goes from simple PR messages to welcome new contributors until configuring the dev environment so it runs on most machines and is configured in a single command line. 

...

• The registry:https://artifactory.magmacore.org/ui/ 

Migration planning: 2022-09-12 Registry migration plan

artifactory.magmacore.org has address 51.178.63.140 (ask for access) ((needs to be moved))

...

Where we host our code, do our project management/bug reporting. 

• Firebase:  https://console.firebase.google.com/u/0/project/magma-ci/authentication/users

It’s the bridge between all github action and our specific nodes (aws/lab/specific architecture..) It also gather a lot of CI stats that are displayed in the CI dashboard

• Vagrant Cloud: https://app.vagrantup.com/magmacore/boxes/magma_dev 

Where we host our images for the dev VM that contains everything to develop on magma (build tools, debugging tools, dependencies, right networking, os etc..)

• 1Password:

For DevOps related credentials.

3.  Main architecture

4. Release process

...

The important repos 

• Apt repo 
  • One for testing: packages-test (local)
  • 2 for production: packages-prod (local) + packages (virtual)
• Docker repo
  • For Testing docker-test (virtual) contains:

  ...

  • • • docker-cwag-test (local)

  ...

  • • • docker-orc8r-test (local)

  ...

  • • • docker-agw-test (local)
    • One for production docker (virtual) contains:
      -
      • • docker-cwag-prod (local)
      -
      • • docker-orc8r-prod (local)
      -
      • • docker-agw-prod (local)
    • Helm repo repo
      • One for testing helm-test (local)
      • 2 for production helm(virtual) contains helm-prod (local)
    • Blob storage storage
      • One for testing blob-test (local)
      • 2 for production blob (virtual) contains blob-prod (local)

    
    AGWPackage grouping:

    
    For the AGW builds, we currently maintain a repository for each release and OS. For example, focal-1.5.4 directory contains the Magma AGW and Sctpd package for release 1.5.4, as well as all third party dependencies of that build. Similarly, focal-1.7.0 tracks the same for Magma release 1.7.0. 
    
    Design choice 1: This leads to duplication of several third-party packages, which do not change across different releases, but have to exist in multiple directories. This is a side-effect of the CI job, which pushes all artifacts to the particular release directory. An obvious fix for this is to modify the CI job to publish all packages to a single repo, but label them such that the package manager can install the correct version of every third-party dependency.
    
    Pydep versioning: Currently the AGW build script creates the python dependency list, which contains the package name and the smallest version of that package which should be installed for the Magma AGW package to work. That is, it contains “pkg_name P>=version V”  to ensure that any version newer than version V of package P is installed before the Magma package is installed.
    
    Design choice 2: Does the “>=” check for package versions create unstable environments when installing Magma AGW? Do we need version pinning, such that all dependencies are pinned with “pkg_name P = version V”. 

    ...