Virtualization Testing VTE

Ideas
1

This is a HOWTO to kick off a discussion on using the virtualization branches in the VTE. This VTE is in the virt branch.

Preparation

Debian Packages

One of the things that is different about this VTE is that it depends on placement of a set of Cogs Debian packages from the outset. Unlike previous VTEs, you cannot simply install the old Cogs packages and then update with the new Cogs binaries or Debian packages as the data store formats are incompatible.

In order to run the virt VTE, you’ll need to build these packages ahead of time

  • rex
  • cog
  • driver
  • cmdr
  • canopy-client
  • canopy-server
  • foundryctl
  • foundryd

and tell the VTE where to find them like so. The paths at that link are my own, update them according to the way your organize your filesystem. All of the artifacts here should be build from their respective virt branches.

MergeTB CLI

When setting up the VTE, you will need to use the CLI from the virt branch the most recent build is available here.

Running

Provisioning

First initialize config.yml as follows

cp site/config-default.yml site/config.yml

Then update the template to look like this

infrapod: 
  moactl:  docker.io/mergetb/moactld:latest
  foundry: docker.io/rgoodfel/foundry:virt
  etcd:    docker.io/mergetb/etcd:latest
  nex:     docker.io/mergetb/nex:latest

Or build the foundry container from the virt branch and use your own container registry endpoint.

Then the regular

./run.sh

will work to get things started. I have only tested this branch with internal authentication, so you’ll need to do the song and dance to get that going.

User setup

# this will give you a 401 error, it's ok, carry on
source local-merge-setup.sh -i reg
# login to user.mergetb.net and create the reg user with the password endicott^2
mergetb login -a internal reg
source local-merge-setup.sh -i reg

Initialization

Next you’ll need to initialize merge as follows

#be sure to use your local MergeTB CLI
alias mergetb='<path-to>/mergetb --cert /tmp/portal-keygen/ca.pem'
mergetb new site spineleaf spineleaf.mergetb.test ~/src/gitlab.com/mergetb/facilities/example/spineleaf/cmd/spineleaf.pbuf 
mergetb cert site spineleaf /tmp/keygen/cmdr.pem
mergetb cert wg spineleaf spineleaf.mergetb.test:36000 site/keygen/wgd.pem
mergetb pubkey ~/.ssh/id_rsa.pub

Exocomp Testing

All exocomp testing takes place from an XDC. In the virt branches, XDCs are project scope. Start by launching an XDC

mergetb new xdc cargobay6

Make sure you have an SSH config like the following

Host *-reg
  Hostname %h
  ProxyJump reg@jumpc.mergetb.io:2202
  ServerAliveInterval 100
  ServerAliveCountMax 2
  ForwardAgent yes
  User reg

Next build the triforce test and copy both onto your XDC

go test -c
scp triforce.{py,test} cargobay6-reg:

triforce.py                100% 1701    93.9KB/s   00:00    
triforce.test              100%   21MB 139.4MB/s   00:00

The triforce.py just happened to be 1701 bytes … did not try for that … it just happened

Next copy the admin keys you’ll need to run exocomp tests

scp /tmp/portal-keygen/merge-admin.pem cargobay6-reg:merge-admin.pem
scp /tmp/keygen/admin.pem cargobay6-reg:facility-admin.pem

Now you should be able to run the triforce test from your XDC.

ssh cargobay6-reg

reg@cargobay6:~$ ./triforce.test -test.v

=== RUN   TestTriforce
    cmdline.go:68: creating experiment triforce
    cmdline.go:124: pushing experiment triforce
    cmdline.go:154: realizing experiment triforce
    portal-admin.go:29: checking allocation table
    portal-admin.go:82: checking n3:p0.one.triforce.reg
    portal-admin.go:82: checking n4:v8.one.triforce.reg
    portal-admin.go:82: checking n7:p1.one.triforce.reg
    portal-admin.go:82: checking n0:p2.one.triforce.reg
    portal-admin.go:82: checking n1:v0.one.triforce.reg
    portal-admin.go:82: checking n1:v1.one.triforce.reg
    portal-admin.go:82: checking n1:v2.one.triforce.reg
    portal-admin.go:82: checking n1:v3.one.triforce.reg
    portal-admin.go:82: checking n2:v4.one.triforce.reg
    portal-admin.go:82: checking n2:v5.one.triforce.reg
    portal-admin.go:82: checking n2:v6.one.triforce.reg
    portal-admin.go:82: checking n2:v7.one.triforce.reg
    cmdline.go:212: materializing realization one.triforce
    cmdline.go:310: attaching one.triforce
    cmdline.go:364: pinging p0
    cmdline.go:364: pinging p1
    cmdline.go:364: pinging p2
    cmdline.go:364: pinging v0
    cmdline.go:364: pinging v1
    cmdline.go:364: pinging v2
    cmdline.go:364: pinging v3
    cmdline.go:364: pinging v4
    cmdline.go:364: pinging v5
    cmdline.go:364: pinging v6
    cmdline.go:364: pinging v7
    cmdline.go:364: pinging v8
    cmdline.go:341: detaching one.triforce
    cmdline.go:246: dematerializing one.triforce
    facility-admin.go:33: checking vms are gone
    triforce_test.go:70: freeing
    cmdline.go:189: freeing realization one.triforce
    portal-admin.go:54: checking for leaked allocations for one.triforce.reg
    cmdline.go:341: detaching one.triforce
    cmdline.go:246: dematerializing one.triforce
    cmdline.go:189: freeing realization one.triforce
    cmdline.go:100: deleting experiment triforce
--- PASS: TestTriforce (180.48s)
PASS

Congratulations, you have now joined the Merge 1.0 testing campaign.

/etc/hosts

2.3.4.10  api.mergetb.net
2.3.4.100 jumpc.mergetb.io xdc.mergetb.io mergetb.io
2.3.4.200 launch.mergetb.net
2.3.4.32  user.mergetb.net
2.3.4.30  login.mergetb.net
2.3.4.99  admin.mergetb.net