There are a number of production NMI Build & Test Facilities around the world, in both the public and commercial sectors. Some of them are described below.
Each group of links goes to the same page. Use whichever host seems fastest at the time.
Status of Runs
The current status of all build and test runs in the UW-Madison NMI Build & Test Facility: nmi-s005 | nmi-s003 | nmi-s001
Status of Machines
The current status of all machines in the UW-Madison NMI Build & Test Facility: nmi-s005 | nmi-s003 | nmi-s001
RSS feed of UW NMI Build and Test Results
Users should feel free to log in and submit jobs from any of the following hosts in the UW-NMI Lab:
The UW-Madison Build & Test Lab is available for use by any of our various project collaborators, and we welcome any affiliated individuals to apply for an account.
Complete this form to request an account in the Build and Test Lab.
You may wish to sign up for relevant NMI Build & Test Lab mailing lists:
Please contact nmi-staff@cs.wisc.edu, Becky Gietzel (bgietzel@cs.wisc.edu) or Nate Griswold (griswold@cs.wisc.edu)
for more information.
Although the Lab’s resources are primarily dedicated to automated build and test jobs, they are also available for interactive debugging when necessary. In order to log in to a specific Metronome node from the public network, you must first ssh into the nmi-net.cs.wisc.edu bastion host using your existing NMI account.
We do not have the resources to dedicate hardare to interactive use, however, so while you should feel free to log in to individual nodes when necessary, we ask that you not use them for regular interactive development work.
If you need to perform builds, tests, or other work which consume significant system resources and may interfere with Metronome jobs running in the background, please contact us first so we can provide you with dedicated access to the necessary resources for a limited period of time.
The NMI Build & Test Facility at CERN supports the ETICS (eInfrastructure for Testing, Integration and Configuration of Software) project, which is coordinated by CERN and funded partially by the European Commission, and aims to improve the quality of Grid and distributed software by offering a practical quality assurance process to software projects, based on a build and test service.
The NMI Build & Test Facility at INFN supports the eInfrastructure for Testing, Integration and Configuration of Software" (ETICS) project, which is coordinated by CERN and funded partially by the European Commission, and aims to improve the quality of Grid and distributed software by offering a practical quality assurance process to software projects, based on a build and test service.
INFN’s NMI Build & Test Facility home page can be found here.
TeraGrid is an open scientific discovery infrastructure combining leadership class resources at nine partner sites to create an integrated, persistent computational resource.
The TeraGrid Build and Test Facility is dynamically deployed on-demand across across distributed TeraGrid resources.
One of the benefits of a grid computing environment is that users are able to widen their access to different resources throughout the world. By leveraging a full-featured batch system, the NMI framework is able to execute jobs on computing resources beyond the local administrative domain. Thus, users may access specific operating system and architecture combinations that may not be available locally.
Currently, an NMI user must declare in their build or test specification file that the platform tasks should be routed to a remote execution site, and must provide the explicit location of that site. In future NMI releases, the system will be able to migrate jobs automatically to remote sites, if a match is unable to be made locally.
For purposes of these instructions, we refer to the site at which the jobs are being submitted as the local site, and the site to which the jobs are being sent as the remote site.
In order to enable the remote site execution, the local Condor installation (that is, the Condor installation where the jobs will be submitted from) must be configured to enable Condor’s grid technologies. As of Condor 6.8, this should be enabled by default.
Another important consideration is the authorization mechanism that the two Condor installations will use to all jobs to execute. For testing purposes, the following parameters can be added to Condor’s configuration file.
SEC_DEFAULT_NEGOTIATION = OPTIONAL
SEC_DEFAULT_AUTHENTICATION_METHODS = CLAIMTOBE
This should only be a temporary option. It is highly advised that you switch to use a more secure Condor authentication mechanism when deploying the NMI framework into production mode.
The remote execution site must be configured to allow outside connections to the Condor daemons. The following options should be included in the remote Condor’s configuration file, where local-condor.example.com is the address of the schedd on the local machine.
HOSTALLOW_WRITE = $(HOSTALLOW_WRITE), local-condor.example.com
HOSTALLOW_READ = $(HOSTALLOW_READ), local-condor.example.com
You may also use the wildcard option to allow an entire domain to communicate with Condor:
HOSTALLOW_WRITE = $(HOSTALLOW_WRITE), *.example.com
HOSTALLOW_READ = $(HOSTALLOW_READ), *.example.com
The remote Condor installation must also specify the authorization method that it will try to negotiate with the other site:
SEC_DEFAULT_NEGOTIATION = OPTIONAL
SEC_DEFAULT_AUTHENTICATION_METHODS = CLAIMTOBE
For information about how to configure Condor to operate correctly through firewalls, please refer to this section of the Condor manual.
More information about Condor’s grid technology can be found in the Condor manual.