tmbgreaves
commented
5 years ago I think this is a good example of a solution that's far too complex and costly for a scientific programmer who doesn't have a systems background. Yes, it's technically elegant, but there are much simpler solutions that will do the job just fine. This is probably a good example of something for a non-systems-technical researcher to avoid.
With a Jenkins instance and its workers entirely located in one Azure Kubernetes Service (AKS) cluster, the limitation of only having one node pool causes problems in a research software testing case. It forces a compromise in terms of the node specification, which makes the instance both cost- and function-impaired. Specifying the virtual machine (VM) size to cater for the largest tests would then require at least one instance of that VM to be running full-time, which would be expensive - on the order of US$1k per month for a 32-core node, for example. Specifying a cost-effective pod to be up full-time to run the master Jenkins service leads to very slow testing on a low-spec node and makes it impossible to run large tests.
The fix for this would be for AKS to support multiple nodepools and provide a learning pathway to configure Jenkins in a way that makes use of this based on node labelling in the Jenkinsfile.