Boot-time Support Endpoints#

Several ICE ClusterWare™ 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 ClusterWare 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 ClusterWare 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 ClusterWare 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 ClusterWare
     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/scyld-install
     Returns a `scyld-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 ClusterWare 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 ClusterWare 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/<PKGSYS>/<NAME>
     Downloads the package named NAME from the head node, where the packaging
     system is determined by PKGSYS.  PKGSYS is one of tar, rpm, or deb.  Note that
     this simply downloads the package and does not install it.

Client Download Endpoints#

ClusterWare 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. 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:

pkgname is a string containing the name of the package to download
pkgtype is one of (rpm, deb, tar, tgz, tar.gz). tar, tgz, and tar.gz are equivalent. Default=rpm
pkgarch is 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

Note

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.

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.

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.