Boot-time Support Endpoints#
Several ClusterWareAI ™ endpoints are designed to support low-level boot-time processes like kickstart, ztp, and ignition:
GET /kickstart/<NAME>
Returns the kickstart file with the given name; the file must already exist and
be located in the /opt/scyld/clusterware/kickstarts directory. The
output format is different from other commands – there are no
“success” or “data” keys, just the (text) file. This endpoint is public and does
not require an authentication token
GET /ztp/script
Returns a ZTP script or config file for a given node; the node is determined by
the incoming connection’s IP address and the node must have its “_boot_config”
attribute set to "ztp:<ZTP_SCRIPTNAME>“. The script must already exist and be
located in the /opt/scyld/clusterware/kickstarts directory. The output
format is different from other commands – there are no “success” or
“data” keys, just the (text) file. This endpoint is public and does not require
an authentication token
GET /ignition/bin
Returns the ignition binary for use by the booting node. The output
format is different from other commands – there are no “success” or
“data” keys, just the (text) file. This endpoint is public and does not require
an authentication token
GET /ignition/<UID>
Returns the ignition configuration file for the node identified by UID; the node
must have its “_ignition” attribute set to the configuration to use. That
configuration may be a URL, a git repo URL, or a locally hosted config file. The
file must already exist and be located in the /opt/scyld/clusterware/kickstarts
directory. The output format is different from other
commands – there are no “success” or “data” keys, just the (text) file. This
endpoint is public and does not require an authentication token
GET /install/head/cw-install
Returns a `cw-install` script that can be used to join a server to the current
head node. This may be useful when automating the creation of multi-head clusters.
The output format is different from other commands – there
are no “success” or “data” keys, just the (text) file. This endpoint is public
and does not require an authentication token
POST /install/password
Accepts a JSON object with an “admin_pass” key and value and verifies that
the password is correct for access to the database. This may be
useful when automating the creation of multi-head clusters. This endpoint is
public and does not require an authentication token
GET /install/repo
Returns a JSON object with a data field containing a repository configuration
suitable for another head node. This may be useful when automating the creation
of multi-head clusters. This endpoint is public and does not require an
authentication token
GET /install/client/installer
Returns a shell script that can be used to install a system with the
clusterware-node package and related monitoring packages. If requested
with no parameters, a “pre-installation” script will be returned that
will attempt to find out the CPU architecture, OS name, and software
packaging system. Alternatively, send the following HTTP parameters and
get a more customized installer script:
cpu=x86_64
specify the CPU architecture; one of x86_64 or aarm64
os=rhel8
specify the OS; one of rhel, debian, cumulus, or sonic
pkg=tar
specify the software packaging system; one of tar, rpm, or deb
If one or more parameters are omitted, then the system will select the installer
that best matches the set of parameters that were sent. Clients must be aware
that a different packaging system may be returned; for example, requesting the
rpm installer may return a tar-based installer instead.
GET /install/client/download
Lists all files available for download. Each file is listed in the
appropriate file type category ("tar", "rpm", or "deb") with its size.
Files with "note": "automated rpm-to-tar conversion" are stored as RPM
files, but can be automatically converted to TAR files on request.
GET /install/client/download/<PKGTYPE>/<PKGARCH>/<PKGNAME>
Downloads the package named PKGNAME from the head node, where the
architecture is determined by PKGARCH and the packaging type is
determined by PKGTYPE. PKGTYPE is one of tar, rpm, or deb. This simply
downloads the package and does not install it.
Only the PKGNAME parameter is required. Omitting the PKGTYPE parameter
assumes the package type is tar. Omitting the PKGARCH parameter assumes
the architecture is x86_64.
Client Download Endpoints#
ClusterWareAI head nodes host a set of user-provided software packages that compute
nodes can download and install. Several packages are pre-populated in the system,
and you can copy your own packages to /opt/scyld/clusterware/clientpkgs
directories to allow clients to download them as well.
Important
In a multi-head cluster, the main directory is not automatically replicated to all head nodes. You must manually add packages to all head nodes.
Use the following to view a list of all available packages:
GET /install/client/download
For a given package, the following endpoints allow the client to define the desired architecture and package type:
/install/client/download/{pkgname}
/install/client/download/{pkgtype}/{pkgname}
/install/client/download/{pkgtype}/{pkgarch}/{pkgname}
Where:
pkgnameis a string containing the name of the package to downloadpkgtypeis one of (rpm, deb, tar, tgz, tar.gz). tar, tgz, and tar.gz are equivalent. Default=rpmpkgarchis one of (x86_64, amd64, aarch64, arm64). X86_64 and amd64 are equivalent; aarch64 and arm64 are equivalent. x86_64/aarch64 are the RHEL/rpm names and amd64/arm64 are the Debian names. Target architecture must be defined or the default will be used. Default = x86_64
Tip
pkgtype and pkgarch can also be defined in HTTP parameters at
the end of the URL. For example:
http://head1.cluster.local/api/v1/download/mypackage?pkg=rpm&arch=x86_64.
For example, use the following to download the clusterware-node package
as a TAR file:
GET /install/client/download/tar/clusterware-node-13.0.0-g0000.cw.el8.x86_64
If you request a tar file, the system first looks for a tar file in the
/opt/scyld/clusterware/clientpkgs/tar directory. If nothing is found there,
the system looks in /opt/scyld/clusterware/clientpkgs/rpm and, if the package
is found, the rpm is converted to tar and stored in
/opt/scyld/clusterware/clientpkgs/tar for future access. This same conversion
rule is in place for all three endpoints.