How to build executable for CBLD environment and run tests

This doc briefly goes over the steps involved in building the plugin for testing inside a deployed Lustre cluster.

Preparation

• Install Docker
• Run the following commands:
  • az login
  • az acr login --name [container-registry-name]
    • This is to allow us to pull images from a private registry called [container-registry-name].
  • docker pull [container-registry-name].azurecr.io/copytoolbuildimage/gobuild

To build the executable

• docker run --name gobuild -v /{path-to-your-lemur-project-code}:/usr/src/lemur -it [container-registry-name].azurecr.io/copytoolbuildimage/gobuild:latest
  • Explanation:
    • We are starting a container that has all the right dependencies built (especially Lustre itself)
    • The -v flag is mapping a path on your machine (the lemur project) into a specific path on the container, so that the source code shows up inside the container.
    • Any changes you make in /usr/src/lemur on the laptop OR in the container should persist.
• cd /usr/src/lemur
  • You should see your lemur project's source code now
• ./build_plugin.sh
  • This step should run for a while, and the output will be in the dist folder

To clean up

• Break out of the container with ‘exit’.
• docker rm gobuild
  • This gets rid of the container so that you can docker run the next time, otherwise the name will be occupied.

How to debug if something goes wrong with compilation

• The environment variables are set appropriately already, but you can examine them with ‘set’ command.
• The most important dependencies to check are:
  • The CGO_CFLAGS which specifies where to look for the C header files
  • The Lustre binaries themselves have to be available to the C compiler, check to make sure
• Check with Joe to see if the image has changed in unexpected ways.

How to test the compiled executable

• Deploy a cluster as the guide specifies
• SSH into the HSM VM (the name starts with 'APRI') by looking up its private IP address in the portal
• Transfer your newly compiled build to that machine (you can do so via a storage container)
• See if the current lhsmd is running:
  • ps -A | grep lhsmd
• Stop the current lhsmd:
  • sudo systemctl stop lhsmd
• Move your new build into /usr/laaso/bin/ with a new name
• Edit the agent config: sudo vi /etc/lhsmd/agent
  • point it to use the new build instead
• Add a new config for the new build: cp /etc/lhsmd/lhsm-plugin-az /etc/lhsmd/lhsm-plugin-new-name
• Either:
  • restart the lhsmd with: sudo systemctl start lhsmd
  • Or better yet run it directly in a separate window: /usr/laaso/bin/lhsmd -config /etc/lhsmd/agent
    • This allows you to see the output directly
• cd /lustre/client
• Exercise the copy tool by triggering restore operations

Extra notes

• The lhsmd config is located at: sudo vi /etc/systemd/system/lhsmd.service
• The plugin config is located at: sudo vi /etc/lhsmd/lhsm-plugin-az
  • The name of the config is the same as the plugin.
  • If you've added new fields to the plugin config, you need to update this file before running lhsmd.
• lhsmd is the parent that starts the plugin, so stopping lhsmd also kills the copy tool
• The sys logs are located at /var/log/daemon.log
• You can trigger multiple file restores:
  • Example:

    IFS=$'\n'; set -f
    for f in $(find /lustre/ST0202 -type f); do lfs hsm_restore "$f"; done
    unset IFS; set +f