Cray System Management Documentation > Cray System Management (CSM) Administration Guide > Boot Orchestration Service (BOS) > BOS API

BOS API

Overview
Server
Kubernetes deployment
Options
Migration job
Specification
Source

Overview

The BOS API is the point of contact for the user and all other services that want to query or update BOS data. This includes the sub-services of BOS.

Server

The BOS API server does not do any of the actual core BOS work – that is, it does not boot or reboot any nodes, it does not coordinate the progress of sessions, and so on. Its essential purpose is to act as a front-end for the BOS database, allowing callers to safely create, read, modify, and delete entries in the database. All of the core BOS work is done by the BOS operators and the BOS reporter.

Other than the API server, there are only two parts of BOS that ever directly access the BOS databases. See BOS database access for details.

Kubernetes deployment

(ncn-mw#) The BOS API server is a Kubernetes deployment in the services namespace:

kubectl get deployments -n services -l app.kubernetes.io/name=cray-bos

Example output:

NAME       READY   UP-TO-DATE   AVAILABLE   AGE
cray-bos   2/2     2            2           11d

(ncn-mw#) The BOS API server runs in multiple Kubernetes pods in the services namespace.

kubectl get pods -n services -l app.kubernetes.io/name=cray-bos

Example output:

NAME                       READY   STATUS    RESTARTS   AGE
cray-bos-994fc7c59-298g8   2/2     Running   0          50d
cray-bos-994fc7c59-z2r2q   2/2     Running   0          50d

Options

Although many of the BOS Options do not impact the behavior of the API server, the following options do:

logging_level
- This option determines the verbosity of BOS logging, including the BOS API server.
- The server logs can be viewed by looking at the logs of the pods in the server Kubernetes deployment.
ims_read_timeout
- This option determines how long the BOS API server will wait for a response to API requests to IMS.
- BOS has other service-specific timeout options; these options would also apply to the BOS API server, but the API server does not make calls to any of those other services.
ims_errors_fatal and ims_images_must_exist
- These options control how BOS deals with IMS issues during boot set validation.
session_limit_required
- This option determines whether or not a session limit is required when creating a new session.
reject_nids
- During boot set validation, this option controls whether NIDs in the node_list field is a fatal error.
- This option controls whether NIDs in the session limit is a fatal error when creating a new session.

See Options for more information.

Migration job

When the cray-bos Kubernetes deployment is upgraded, the cray-bos-migration job runs in the services namespace. It checks data in the BOS databases and fixes some cases of invalid data (for example, session template names that are not legal under the API Specification.

The migration job pods first wait until all of the databases are accessible. In some cases, this will time out before the databases are ready, and the pod will exit in failure. The job migration automatically retries when the pod fails; in most cases, the databases are ready in time when the next migration job pod runs.

Specification

For a user-friendly summary of the BOS API specification, see Boot Orchestration Service API. For the full OpenAPI specification, see the Cray-HPE/bos open source GitHub repository.

Source

For the source for the BOS API server, including its Helm chart, see the Cray-HPE/bos open source GitHub repository.