You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Page about kubernetes clusters ad-build and ad-build-dev

Background information

  1. Runs on hardware in s3df

    Allocatable:
      cpu:                64
      ephemeral-storage:  152933498761
      hugepages-1Gi:      0
      hugepages-2Mi:      2816Mi
      memory:             259679512Ki
      pods:               220
    System Info:
      Machine ID:                 92faa81e90af4e65ba73d3007e42519e
      System UUID:                ce9ba000-5727-11ed-8000-3cecefd8e38e
      Boot ID:                    96386228-b4ab-4836-b764-b22d4dfc0cda
      Kernel Version:             4.18.0-372.32.1.el8_6.x86_64
      OS Image:                   Red Hat Enterprise Linux 8.6 (Ootpa)
      Operating System:           linux
      Architecture:               amd64
      Container Runtime Version:  containerd://1.6.31
      Kubelet Version:            v1.28.8
      Kube-Proxy Version:         v1.28.8

How to access

ad-build-dev cluster: https://k8s.slac.stanford.edu/ad-build-dev

ad-build cluster: https://k8s.slac.stanford.edu/ad-build

  1. After following the commands in those links, you will need to request access to the cluster from Claudio.
  2. Recommended to install k9s tool https://k9scli.io/topics/install/

Other Notes

  1. Kubernetes cluster is intended to be just for build system. 
  2. Can use local machine or nodes in the kubernetes cluster to create docker images (Don't need access to s3df/afs filesystem if all modules/dependencies are uploaded to GitHub, as they should be)
  3. Docker can be ran on local machine, but not on s3df, it is intended to use apptainer instead, if build enviornment wants to be passed around. So when this build system is finished, developers/users won't use docker directly, instead will use apptainer and pull docker images from artifact storage (if needed)

Current

  1. Get the build system container running on the kluster, see if you can use the actions/actions-runner-controller: Kubernetes controller for GitHub Actions self-hosted runners
  2. Then we can use that for building buildroot. One of the workflows will be it checking out on /scratch/ in s3df, then build, and output results there.


  • No labels