sls_client

package

v0.4.0 Latest Latest Go to latest Published: Dec 12, 2023 License: MIT Imports: 23 Imported by: 0

Details

Valid go.mod file
Redistributable license
Tagged version
Stable version
Learn more about best practices

Repository

github.com/Cray-HPE/cani

Links

Open Source Insights

README ¶

Go API client for sls_client

System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like "comptype_ncard", "comptype_cabinet". * Class – kind of hardware like "River" or "Mountain" * TypeString – a human readable type like "Cabinet" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include "Network", "IP6Prefix", "IP4Base", "MACprefix" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of "?parent=x0" would return a list of all children of cabinet x0. A query string of "?type=comptype_node" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified.

Overview

This API client was generated by the swagger-codegen project. By using the swagger-spec from a remote server, you can easily generate an API client.

API version: 0.1
Package version: 1.0.0
Build package: io.swagger.codegen.v3.generators.go.GoClientCodegen

Installation

Put the package under your project folder and add the following in import:

import "./sls_client"

Documentation for API Endpoints

All URIs are relative to https://api-gw-service-nmn.local/apis/sls/v1

Class	Method	HTTP request	Description
CliFromFileApi	LoadstatePost	Post /loadstate	Load services state and overwrite current service state
CliFromFileApi	NetworksNetworkPut	Put /networks/{network}	Update a network object
CliFromFileApi	NetworksPost	Post /networks	Create a new network
CliIgnoreApi	LivenessGet	Get /liveness	Kubernetes liveness endpoint to monitor service health
CliIgnoreApi	ReadinessGet	Get /readiness	Kubernetes readiness endpoint to monitor service health
DumpstateApi	DumpstateGet	Get /dumpstate	Retrieve a dump of current service state
DumpstateApi	LoadstatePost	Post /loadstate	Load services state and overwrite current service state
HardwareApi	HardwareGet	Get /hardware	Retrieve a list of hardware in the system.
HardwareApi	HardwarePost	Post /hardware	Create a new hardware object
HardwareApi	HardwareXnameDelete	Delete /hardware/{xname}	Delete the xname
HardwareApi	HardwareXnameGet	Get /hardware/{xname}	Retrieve information about the requested xname
HardwareApi	HardwareXnamePut	Put /hardware/{xname}	Update a hardware object
MiscApi	HealthGet	Get /health	Query the health of the service
MiscApi	LivenessGet	Get /liveness	Kubernetes liveness endpoint to monitor service health
MiscApi	ReadinessGet	Get /readiness	Kubernetes readiness endpoint to monitor service health
MiscApi	VersionGet	Get /version	Retrieve versioning information on the information in SLS
NetworkApi	NetworksGet	Get /networks	Retrieve a list of networks in the system
NetworkApi	NetworksNetworkDelete	Delete /networks/{network}	Delete the named network
NetworkApi	NetworksNetworkGet	Get /networks/{network}	Retrieve a network item
NetworkApi	NetworksNetworkPut	Put /networks/{network}	Update a network object
NetworkApi	NetworksPost	Post /networks	Create a new network
SearchApi	SearchHardwareGet	Get /search/hardware	Search for nodes matching a set of criteria
SearchApi	SearchNetworksGet	Get /search/networks	Perform a search for networks matching a set of criteria.

Documentation For Models

Documentation For Authorization

Endpoints do not require authorization.

Author

Documentation ¶

Overview ¶

System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)

This is custom code that is not generated by swagger-codegen The SLS Hardware extra proeprteis is context dependent with different structs allowed. The code generate does struct compoistion, and things are not well behaved when performing JSON unmarshalling if multiple of these structs have the same field which causes these fields to be ignored.

System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)
System Layout Service *
System Layout Service (SLS) holds information on the complete, designed system. SLS gets this information from an input file on the system. Besides information like what hardware should be present in a system, SLS also stores information about what network connections exist and what power connections exist. SLS details the physical locations of network hardware, compute nodes and cabinets. Further, it stores information about the network, such as which port on which switch should be connected to each compute node. The API allows updating this information as well. Note that SLS is not responsible for verifying that the system is set up correctly. It only lets the Shasta system know what the system should be configured with. SLS does not store the details of the actual hardware like hardware identifiers. Instead it stores a generalized abstraction of the system that other services may use. SLS thus does not need to change as hardware within the system is replaced. Interaction with SLS is required if the system setup changes – for example, if system cabling is altered or during installation, expansion, or reduction. SLS does not interact with the hardware. Each object in SLS has the following basic properties: * Parent – Each object in SLS has a parent object except the system root (s0). * Children – Objects may have children. * xname – Every object has an xname – a unique identifier for that object. * Type – a hardware type like \"comptype_ncard\", \"comptype_cabinet\". * Class – kind of hardware like \"River\" or \"Mountain\" * TypeString – a human readable type like \"Cabinet\" Some objects may have additional properties depending on their type. For example, additional properties for cabinets include \"Network\", \"IP6Prefix\", \"IP4Base\", \"MACprefix\" etc. ## Resources ### /hardware Create hardware entries in SLS. This resource can be used when you add new components or expand your system. Interaction with this resource is not required if a component is removed or replaced. ### /hardware/{xname} Retrieve, update, or delete information about specific xnames. ### /search/hardware Uses HTTP query parameters to find hardware entries with matching properties. Returns a JSON list of xnames. If multiple query parameters are passed, any returned hardware must match all parameters. For example, a query string of \"?parent=x0\" would return a list of all children of cabinet x0. A query string of \"?type=comptype_node\" would return a list of all compute nodes. Valid query parameters are: xname, parent, class, type, power_connector, node_nics, networks, peers. ### /search/networks Uses HTTP query parameters to find network entries with matching properties. ### /networks Create new network objects or retrieve networks available in the system. ### /networks/{network} Retrieve, update, or delete information about specific networks. ### /dumpstate Dumps the current database state of the service. This may be useful when you are backing up the system or planning a reinstall of the system. ### /loadstate Upload and overwrite the current database with the contents of the posted data. The posted data should be a state dump from /dumpstate. This may be useful to restore the SLS database after you have reinstalled the system. ## Workflows ### Backup and Restore the SLS Database for Reinstallation #### GET /dumpstate Perform a dump of the current state of the SLS data. This should be done before reinstalling the system. The database dump is a JSON blob in an SLS-specific format. #### POST /loadstate Reimport the dump from /dumpstate and restore the SLS database after reinstall. ### Expand System #### POST /hardware Add the new hardware objects. #### GET /hardware/{xname} Review hardware properties of the xname from the JSON array. ### Remove Hardware #### DELETE /hardware Remove hardware from SLS ### Modify Hardware Properties #### PATCH /hardware Modify hardware properties in SLS. Only additional properties can be modified. Basic properties like xname, parent, children, type, class, typestring cannot be modified. *
API version: 0.1
Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-codegen.git)

Index ¶

Variables
func CacheExpires(r *http.Response) time.Time
type APIClient
- func NewAPIClient(cfg *Configuration) *APIClient
- func (c *APIClient) ChangeBasePath(path string)
type APIKey
type APIResponse
- func NewAPIResponse(r *http.Response) *APIResponse
- func NewAPIResponseWithError(errorMessage string) *APIResponse
type BasicAuth
type CaniStatus
type CliFromFileApiLoadstatePostOpts
type CliFromFileApiNetworksNetworkPutOpts
type CliFromFileApiNetworksPostOpts
type CliFromFileApiService
- func (a *CliFromFileApiService) LoadstatePost(ctx context.Context, localVarOptionals *CliFromFileApiLoadstatePostOpts) (*http.Response, error)
- func (a *CliFromFileApiService) NetworksNetworkPut(ctx context.Context, network string, ...) (Network, *http.Response, error)
- func (a *CliFromFileApiService) NetworksPost(ctx context.Context, localVarOptionals *CliFromFileApiNetworksPostOpts) (*http.Response, error)
type CliIgnoreApiService
- func (a *CliIgnoreApiService) LivenessGet(ctx context.Context) (*http.Response, error)
- func (a *CliIgnoreApiService) ReadinessGet(ctx context.Context) (*http.Response, error)
type Configuration
- func NewConfiguration() *Configuration
- func (c *Configuration) AddDefaultHeader(key string, value string)
type DumpstateApiLoadstatePostOpts
type DumpstateApiService
- func (a *DumpstateApiService) DumpstateGet(ctx context.Context) (SlsState, *http.Response, error)
- func (a *DumpstateApiService) LoadstatePost(ctx context.Context, localVarOptionals *DumpstateApiLoadstatePostOpts) (*http.Response, error)
type GenericSwaggerError
- func (e GenericSwaggerError) Body() []byte
- func (e GenericSwaggerError) Error() string
- func (e GenericSwaggerError) Model() interface{}
type Hardware
- func (hardware *Hardware) DecodeExtraProperties() (result interface{}, err error)
type HardwareApiHardwarePostOpts
type HardwareApiHardwareXnamePutOpts
type HardwareApiService
- func (a *HardwareApiService) HardwareGet(ctx context.Context) ([]Hardware, *http.Response, error)
- func (a *HardwareApiService) HardwarePost(ctx context.Context, localVarOptionals *HardwareApiHardwarePostOpts) (Hardware, *http.Response, error)
- func (a *HardwareApiService) HardwareXnameDelete(ctx context.Context, xname string) (*http.Response, error)
- func (a *HardwareApiService) HardwareXnameGet(ctx context.Context, xname string) (Hardware, *http.Response, error)
- func (a *HardwareApiService) HardwareXnamePut(ctx context.Context, xname string, ...) (Hardware, *http.Response, error)
type HardwareBmc
type HardwareClass
type HardwareExtraProperties
type HardwareExtraPropertiesBmcNic
type HardwareExtraPropertiesCabPduNic
type HardwareExtraPropertiesCabPduPwrConnector
type HardwareExtraPropertiesCabinet
type HardwareExtraPropertiesCabinetNetworks
type HardwareExtraPropertiesCduMgmtSwitch
type HardwareExtraPropertiesChassis
type HardwareExtraPropertiesChassisBmc
type HardwareExtraPropertiesCompmod
type HardwareExtraPropertiesCompmodPowerConnector
type HardwareExtraPropertiesHsnConnector
type HardwareExtraPropertiesMgmtHlSwitch
type HardwareExtraPropertiesMgmtSwitch
type HardwareExtraPropertiesMgmtSwitchConnector
type HardwareExtraPropertiesNcard
type HardwareExtraPropertiesNode
type HardwareExtraPropertiesNodeHsnNic
type HardwareExtraPropertiesNodeNic
type HardwareExtraPropertiesRtrBmc
type HardwareExtraPropertiesRtrBmcNic
type HardwareExtraPropertiesRtrmod
type HardwareExtraPropertiesSystem
type HardwareIpAndCredsOptional
type HardwareNic
type HardwarePost
type HardwarePoweredDevice
type HardwarePut
type HardwarePwrConnector
type HardwareType
type InlineResponse200
type LoadstateBody
type MiscApiService
- func (a *MiscApiService) HealthGet(ctx context.Context) (InlineResponse200, *http.Response, error)
- func (a *MiscApiService) LivenessGet(ctx context.Context) (*http.Response, error)
- func (a *MiscApiService) ReadinessGet(ctx context.Context) (*http.Response, error)
- func (a *MiscApiService) VersionGet(ctx context.Context) (VersionResponse, *http.Response, error)
type Network
type NetworkApiNetworksNetworkPutOpts
type NetworkApiNetworksPostOpts
type NetworkApiService
- func (a *NetworkApiService) NetworksGet(ctx context.Context) ([]Network, *http.Response, error)
- func (a *NetworkApiService) NetworksNetworkDelete(ctx context.Context, network string) (*http.Response, error)
- func (a *NetworkApiService) NetworksNetworkGet(ctx context.Context, network string) (Network, *http.Response, error)
- func (a *NetworkApiService) NetworksNetworkPut(ctx context.Context, network string, ...) (Network, *http.Response, error)
- func (a *NetworkApiService) NetworksPost(ctx context.Context, localVarOptionals *NetworkApiNetworksPostOpts) (*http.Response, error)
type NetworkExtraProperties
type NetworkIpReservation
type NetworkIpv4Subnet
type Problem7807
type SearchApiSearchHardwareGetOpts
type SearchApiSearchNetworksGetOpts
type SearchApiService
- func (a *SearchApiService) SearchHardwareGet(ctx context.Context, localVarOptionals *SearchApiSearchHardwareGetOpts) ([]Hardware, *http.Response, error)
- func (a *SearchApiService) SearchNetworksGet(ctx context.Context, localVarOptionals *SearchApiSearchNetworksGetOpts) ([]Network, *http.Response, error)
type SlsState
type VersionResponse

Constants ¶

This section is empty.

Variables ¶

View Source

var (
	// ContextOAuth2 takes a oauth2.TokenSource as authentication for the request.
	ContextOAuth2 = contextKey("token")

	// ContextBasicAuth takes BasicAuth as authentication for the request.
	ContextBasicAuth = contextKey("basic")

	// ContextAccessToken takes a string oauth2 access token as authentication for the request.
	ContextAccessToken = contextKey("accesstoken")

	// ContextAPIKey takes an APIKey as authentication for the request
	ContextAPIKey = contextKey("apikey")
)

Functions ¶

func CacheExpires ¶

func CacheExpires(r *http.Response) time.Time

CacheExpires helper function to determine remaining time before repeating a request.

Types ¶

type APIClient ¶

type APIClient struct {
	CliFromFileApi *CliFromFileApiService

	CliIgnoreApi *CliIgnoreApiService

	DumpstateApi *DumpstateApiService

	HardwareApi *HardwareApiService

	MiscApi *MiscApiService

	NetworkApi *NetworkApiService

	SearchApi *SearchApiService
	// contains filtered or unexported fields
}

APIClient manages communication with the System Layout Service API v0.1 In most cases there should be only one, shared, APIClient.

func NewAPIClient ¶

func NewAPIClient(cfg *Configuration) *APIClient

NewAPIClient creates a new API client. Requires a userAgent string describing your application. optionally a custom http.Client to allow for advanced features such as caching.

func (*APIClient) ChangeBasePath ¶

func (c *APIClient) ChangeBasePath(path string)

Change base path to allow switching to mocks

type APIKey ¶

type APIKey struct {
	Key    string
	Prefix string
}

APIKey provides API key based authentication to a request passed via context using ContextAPIKey

type APIResponse ¶

type APIResponse struct {
	*http.Response `json:"-"`
	Message        string `json:"message,omitempty"`
	// Operation is the name of the swagger operation.
	Operation string `json:"operation,omitempty"`
	// RequestURL is the request URL. This value is always available, even if the
	// embedded *http.Response is nil.
	RequestURL string `json:"url,omitempty"`
	// Method is the HTTP method used for the request.  This value is always
	// available, even if the embedded *http.Response is nil.
	Method string `json:"method,omitempty"`
	// Payload holds the contents of the response body (which may be nil or empty).
	// This is provided here as the raw response.Body() reader will have already
	// been drained.
	Payload []byte `json:"-"`
}

func NewAPIResponse ¶

func NewAPIResponse(r *http.Response) *APIResponse

func NewAPIResponseWithError ¶

func NewAPIResponseWithError(errorMessage string) *APIResponse

type BasicAuth ¶

type BasicAuth struct {
	UserName string `json:"userName,omitempty"`
	Password string `json:"password,omitempty"`
}

BasicAuth provides basic http authentication to a request passed via context using ContextBasicAuth

type CaniStatus ¶ added in v0.3.0

type CaniStatus string

const (
	EMPTY_CaniStatus          CaniStatus = "empty"
	STAGED_CaniStatus         CaniStatus = "staged"
	PROVISIONED_CaniStatus    CaniStatus = "provisioned"
	DECOMMISSIONED_CaniStatus CaniStatus = "decommissioned"
)

List of CANIStatus

type CliFromFileApiLoadstatePostOpts ¶

type CliFromFileApiLoadstatePostOpts struct {
	SlsDump optional.Interface
}

type CliFromFileApiNetworksNetworkPutOpts ¶

type CliFromFileApiNetworksNetworkPutOpts struct {
	Body optional.Interface
}

type CliFromFileApiNetworksPostOpts ¶

type CliFromFileApiNetworksPostOpts struct {
	Body optional.Interface
}

type CliFromFileApiService ¶

type CliFromFileApiService service

func (*CliFromFileApiService) LoadstatePost ¶

func (a *CliFromFileApiService) LoadstatePost(ctx context.Context, localVarOptionals *CliFromFileApiLoadstatePostOpts) (*http.Response, error)

func (*CliFromFileApiService) NetworksNetworkPut ¶

func (a *CliFromFileApiService) NetworksNetworkPut(ctx context.Context, network string, localVarOptionals *CliFromFileApiNetworksNetworkPutOpts) (Network, *http.Response, error)

func (*CliFromFileApiService) NetworksPost ¶

func (a *CliFromFileApiService) NetworksPost(ctx context.Context, localVarOptionals *CliFromFileApiNetworksPostOpts) (*http.Response, error)

type CliIgnoreApiService ¶

type CliIgnoreApiService service

func (*CliIgnoreApiService) LivenessGet ¶

func (a *CliIgnoreApiService) LivenessGet(ctx context.Context) (*http.Response, error)

CliIgnoreApiService Kubernetes liveness endpoint to monitor service health The `liveness` resource works in conjunction with the Kubernetes liveness probe to determine when the service is no longer responding to requests. Too many failures of the liveness probe will result in the service being shut down and restarted. This is primarily an endpoint for the automated Kubernetes system.

@param ctx context.Context - for authentication, logging, cancellation, deadlines, tracing, etc. Passed from http.Request or context.Background().

func (*CliIgnoreApiService) ReadinessGet ¶

func (a *CliIgnoreApiService) ReadinessGet(ctx context.Context) (*http.Response, error)

CliIgnoreApiService Kubernetes readiness endpoint to monitor service health The `readiness` resource works in conjunction with the Kubernetes readiness probe to determine when the service is no longer healthy and able to respond correctly to requests. Too many failures of the readiness probe will result in the traffic being routed away from this service and eventually the service will be shut down and restarted if in an unready state for too long. This is primarily an endpoint for the automated Kubernetes system.

@param ctx context.Context - for authentication, logging, cancellation, deadlines, tracing, etc. Passed from http.Request or context.Background().

type Configuration ¶

type Configuration struct {
	BasePath      string            `json:"basePath,omitempty"`
	Host          string            `json:"host,omitempty"`
	Scheme        string            `json:"scheme,omitempty"`
	DefaultHeader map[string]string `json:"defaultHeader,omitempty"`
	UserAgent     string            `json:"userAgent,omitempty"`
	HTTPClient    *http.Client
}

func NewConfiguration ¶

func NewConfiguration() *Configuration

func (*Configuration) AddDefaultHeader ¶

func (c *Configuration) AddDefaultHeader(key string, value string)

type DumpstateApiLoadstatePostOpts ¶

type DumpstateApiLoadstatePostOpts struct {
	SlsDump optional.Interface
}

type DumpstateApiService ¶

type DumpstateApiService service

func (*DumpstateApiService) DumpstateGet ¶

func (a *DumpstateApiService) DumpstateGet(ctx context.Context) (SlsState, *http.Response, error)

DumpstateApiService Retrieve a dump of current service state Get a dump of current service state. The format of this is implementation-specific.

@param ctx context.Context - for authentication, logging, cancellation, deadlines, tracing, etc. Passed from http.Request or context.Background().

@return SlsState

func (*DumpstateApiService) LoadstatePost ¶

func (a *DumpstateApiService) LoadstatePost(ctx context.Context, localVarOptionals *DumpstateApiLoadstatePostOpts) (*http.Response, error)

type GenericSwaggerError ¶

type GenericSwaggerError struct {
	// contains filtered or unexported fields
}

GenericSwaggerError Provides access to the body, error and model on returned errors.

func (GenericSwaggerError) Body ¶

func (e GenericSwaggerError) Body() []byte

Body returns the raw bytes of the response

func (GenericSwaggerError) Error ¶

func (e GenericSwaggerError) Error() string

Error returns non-empty string if there was an error.

func (GenericSwaggerError) Model ¶

func (e GenericSwaggerError) Model() interface{}

Model returns the unpacked model of the error

type Hardware ¶

type Hardware struct {
	// The xname of the parent of this piece of hardware
	Parent          string                  `json:"Parent,omitempty"`
	Xname           string                  `json:"Xname"`
	Children        []string                `json:"Children,omitempty"`
	Type            HardwareType            `json:"Type,omitempty"`
	TypeString      xnametypes.HMSType      `json:"TypeString,omitempty"`
	Class           HardwareClass           `json:"Class"`
	LastUpdated     int32                   `json:"LastUpdated,omitempty"`
	LastUpdatedTime string                  `json:"LastUpdatedTime,omitempty"`
	ExtraProperties HardwareExtraProperties `json:"ExtraProperties,omitempty"`
}

func (*Hardware) DecodeExtraProperties ¶

func (hardware *Hardware) DecodeExtraProperties() (result interface{}, err error)

type HardwareApiHardwarePostOpts ¶

type HardwareApiHardwarePostOpts struct {
	Body optional.Interface
}

type HardwareApiHardwareXnamePutOpts ¶

type HardwareApiHardwareXnamePutOpts struct {
	Body optional.Interface
}

type HardwareApiService ¶

type HardwareApiService service

func (*HardwareApiService) HardwareGet ¶

func (a *HardwareApiService) HardwareGet(ctx context.Context) ([]Hardware, *http.Response, error)

HardwareApiService Retrieve a list of hardware in the system. Retrieve a JSON list of the networks available in the system. Return value is an array of hardware objects representing all the hardware in the system.

@param ctx context.Context - for authentication, logging, cancellation, deadlines, tracing, etc. Passed from http.Request or context.Background().

@return []Hardware

func (*HardwareApiService) HardwarePost ¶

func (a *HardwareApiService) HardwarePost(ctx context.Context, localVarOptionals *HardwareApiHardwarePostOpts) (Hardware, *http.Response, error)

func (*HardwareApiService) HardwareXnameDelete ¶

func (a *HardwareApiService) HardwareXnameDelete(ctx context.Context, xname string) (*http.Response, error)

HardwareApiService Delete the xname Delete the requested xname from SLS. Note that if you delete a parent object, then the children are also deleted from SLS. If the child object happens to be a parent, then the deletion can cascade down levels. If you delete a child object, it does not affect the parent.

@param ctx context.Context - for authentication, logging, cancellation, deadlines, tracing, etc. Passed from http.Request or context.Background().
@param xname The xname to look up or alter.

func (*HardwareApiService) HardwareXnameGet ¶

func (a *HardwareApiService) HardwareXnameGet(ctx context.Context, xname string) (Hardware, *http.Response, error)

HardwareApiService Retrieve information about the requested xname Retrieve information about the requested xname. All properties are returned as a JSON array.

@param ctx context.Context - for authentication, logging, cancellation, deadlines, tracing, etc. Passed from http.Request or context.Background().
@param xname The xname to look up or alter.

@return Hardware

func (*HardwareApiService) HardwareXnamePut ¶

func (a *HardwareApiService) HardwareXnamePut(ctx context.Context, xname string, localVarOptionals *HardwareApiHardwareXnamePutOpts) (Hardware, *http.Response, error)

type HardwareBmc ¶

type HardwareBmc struct {
	// The ipv6 address that should be assigned to this BMC, or \"DHCPv6\".  If omitted, \"DHCPv6\" is assumed.
	IP6addr string `json:"IP6addr"`
	// The ipv4 address that should be assigned to this BMC, or \"DHCPv4\".  If omitted, \"DHCPv4\" is assumed.
	IP4addr string `json:"IP4addr"`
	// The username that should be used to access the device (or be assigned to the device)
	Username string `json:"Username,omitempty"`
	// The password that should be used to access the device (or be assigned to the device)
	Password string `json:"Password,omitempty"`
}

type HardwareClass ¶

type HardwareClass string

HardwareClass : The hardware class.

const (
	HardwareClassRiver    HardwareClass = "River"
	HardwareClassMountain HardwareClass = "Mountain"
	HardwareClassHill     HardwareClass = "Hill"
)

List of hardware_class

type HardwareExtraProperties ¶

type HardwareExtraProperties interface{}

type HardwareExtraPropertiesBmcNic ¶

type HardwareExtraPropertiesBmcNic struct {
	CaniId               string      `json:"@cani.id,omitempty" mapstructure:"@cani.id"`
	CaniLastModified     string      `json:"@cani.lastModified,omitempty" mapstructure:"@cani.lastModified"`
	CaniSlsSchemaVersion string      `json:"@cani.slsSchemaVersion,omitempty" mapstructure:"@cani.slsSchemaVersion"`
	CaniStatus           *CaniStatus `json:"@cani.status,omitempty" mapstructure:"@cani.status"`
	// The ipv6 address that should be assigned to this BMC, or \"DHCPv6\". If omitted, \"DHCPv6\" is assumed.
	IP6addr string `json:"IP6addr" mapstructure:"IP6addr"`
	// The ipv4 address that should be assigned to this BMC, or \"DHCPv4\".  If omitted, \"DHCPv4\" is assumed.
	IP4addr string `json:"IP4addr" mapstructure:"IP4addr"`
	// The username that should be used to access the device (or be assigned to the device)
	Username string `json:"Username" mapstructure:"Username"`
	// The password that should be used to access the device
	Password string `json:"Password" mapstructure:"Password"`
}

type HardwareExtraPropertiesCabPduNic ¶

type HardwareExtraPropertiesCabPduNic struct {
	CaniId               string      `json:"@cani.id,omitempty" mapstructure:"@cani.id"`
	CaniLastModified     string      `json:"@cani.lastModified,omitempty" mapstructure:"@cani.lastModified"`
	CaniSlsSchemaVersion string      `json:"@cani.slsSchemaVersion,omitempty" mapstructure:"@cani.slsSchemaVersion"`
	CaniStatus           *CaniStatus `json:"@cani.status,omitempty" mapstructure:"@cani.status"`
	// An array of network names that this NIC is connected to
	Networks []string `json:"Networks" mapstructure:"Networks"`
	// An array of xnames this NIC is connected directly to.  These ideally connector xnames, not switches
	Peers []string `json:"Peers" mapstructure:"Peers"`
}

type HardwareExtraPropertiesCabPduPwrConnector ¶

type HardwareExtraPropertiesCabPduPwrConnector struct {
	CaniId               string      `json:"@cani.id,omitempty" mapstructure:"@cani.id"`
	CaniLastModified     string      `json:"@cani.lastModified,omitempty" mapstructure:"@cani.lastModified"`
	CaniSlsSchemaVersion string      `json:"@cani.slsSchemaVersion,omitempty" mapstructure:"@cani.slsSchemaVersion"`
	CaniStatus           *CaniStatus `json:"@cani.status,omitempty" mapstructure:"@cani.status"`
	PoweredBy            string      `json:"PoweredBy" mapstructure:"PoweredBy"`
}

type HardwareExtraPropertiesCabinet ¶

type HardwareExtraPropertiesCabinet struct {
	CaniId               string      `json:"@cani.id,omitempty" mapstructure:"@cani.id"`
	CaniLastModified     string      `json:"@cani.lastModified,omitempty" mapstructure:"@cani.lastModified"`
	CaniSlsSchemaVersion string      `json:"@cani.slsSchemaVersion,omitempty" mapstructure:"@cani.slsSchemaVersion"`
	CaniStatus           *CaniStatus `json:"@cani.status,omitempty" mapstructure:"@cani.status"`
	Model                string      `json:"Model,omitempty"`
	// Networks has at the top the hardware type, then inside of that the network ID, then inside of that the object.
	Networks          map[string]map[string]HardwareExtraPropertiesCabinetNetworks `json:"Networks,omitempty"`
	DHCPRelaySwitches []string                                                     `json:"DHCPRelaySwitches,omitempty"`
}

type HardwareExtraPropertiesCabinetNetworks ¶

type HardwareExtraPropertiesCabinetNetworks struct {
	CIDR       string `json:"CIDR,omitempty" mapstructure:"CIDR"`
	Gateway    string `json:"Gateway,omitempty" mapstructure:"Gateway"`
	VLan       int32  `json:"VLan,omitempty" mapstructure:"VLan"`
	IPv6Prefix string `json:"IPv6Prefix,omitempty" mapstructure:"IPv6Prefix"`
	MACPrefix  string `json:"MACPrefix,omitempty" mapstructure:"MACPrefix"`
}

type HardwareExtraPropertiesCduMgmtSwitch ¶

type HardwareExtraPropertiesCduMgmtSwitch struct {
	CaniId               string      `json:"@cani.id,omitempty" mapstructure:"@cani.id"`
	CaniLastModified     string      `json:"@cani.lastModified,omitempty" mapstructure:"@cani.lastModified"`
	CaniSlsSchemaVersion string      `json:"@cani.slsSchemaVersion,omitempty" mapstructure:"@cani.slsSchemaVersion"`
	CaniStatus           *CaniStatus `json:"@cani.status,omitempty" mapstructure:"@cani.status"`
	Brand                string      `json:"Brand,omitempty" mapstructure:"Brand"`
	Model                string      `json:"Model,omitempty" mapstructure:"Model"`
	Aliases              []string    `json:"Aliases,omitempty" mapstructure:"Aliases"`
}

type HardwareExtraPropertiesChassis ¶

type HardwareExtraPropertiesChassis struct {
	CaniId               string      `json:"@cani.id,omitempty" mapstructure:"@cani.id"`
	CaniLastModified     string      `json:"@cani.lastModified,omitempty" mapstructure:"@cani.lastModified"`
	CaniSlsSchemaVersion string      `json:"@cani.slsSchemaVersion,omitempty" mapstructure:"@cani.slsSchemaVersion"`
	CaniStatus           *CaniStatus `json:"@cani.status,omitempty" mapstructure:"@cani.status"`
}

type HardwareExtraPropertiesChassisBmc ¶

type HardwareExtraPropertiesChassisBmc struct {
	CaniId               string      `json:"@cani.id,omitempty" mapstructure:"@cani.id"`
	CaniLastModified     string      `json:"@cani.lastModified,omitempty" mapstructure:"@cani.lastModified"`
	CaniSlsSchemaVersion string      `json:"@cani.slsSchemaVersion,omitempty" mapstructure:"@cani.slsSchemaVersion"`
	CaniStatus           *CaniStatus `json:"@cani.status,omitempty" mapstructure:"@cani.status"`
	Aliases              []string    `json:"Aliases,omitempty" mapstructure:"Aliases"`
}

type HardwareExtraPropertiesCompmod ¶

type HardwareExtraPropertiesCompmod struct {
	CaniId               string      `json:"@cani.id,omitempty" mapstructure:"@cani.id"`
	CaniLastModified     string      `json:"@cani.lastModified,omitempty" mapstructure:"@cani.lastModified"`
	CaniSlsSchemaVersion string      `json:"@cani.slsSchemaVersion,omitempty" mapstructure:"@cani.slsSchemaVersion"`
	CaniStatus           *CaniStatus `json:"@cani.status,omitempty" mapstructure:"@cani.status"`
	// An array of xnames, where each xname has type==*_pwr_connector.  Empty for Mountain switch cards
	PowerConnector []string `json:"PowerConnector" mapstructure:"PowerConnector"`
}

type HardwareExtraPropertiesCompmodPowerConnector ¶

type HardwareExtraPropertiesCompmodPowerConnector struct {
	CaniId               string      `json:"@cani.id,omitempty" mapstructure:"@cani.id"`
	CaniLastModified     string      `json:"@cani.lastModified,omitempty" mapstructure:"@cani.lastModified"`
	CaniSlsSchemaVersion string      `json:"@cani.slsSchemaVersion,omitempty" mapstructure:"@cani.slsSchemaVersion"`
	CaniStatus           *CaniStatus `json:"@cani.status,omitempty" mapstructure:"@cani.status"`
	PoweredBy            string      `json:"PoweredBy" mapstructure:"PoweredBy"`
}

type HardwareExtraPropertiesHsnConnector ¶

type HardwareExtraPropertiesHsnConnector struct {
	CaniId               string      `json:"@cani.id,omitempty" mapstructure:"@cani.id"`
	CaniLastModified     string      `json:"@cani.lastModified,omitempty" mapstructure:"@cani.lastModified"`
	CaniSlsSchemaVersion string      `json:"@cani.slsSchemaVersion,omitempty" mapstructure:"@cani.slsSchemaVersion"`
	CaniStatus           *CaniStatus `json:"@cani.status,omitempty" mapstructure:"@cani.status"`
	// An array of xnames that this connector is connected to.  All xnames should have type==comptype_hsn_connector_port
	NodeNics []string `json:"NodeNics" mapstructure:"NodeNics"`
}

type HardwareExtraPropertiesMgmtHlSwitch ¶

type HardwareExtraPropertiesMgmtHlSwitch struct {
	CaniId               string      `json:"@cani.id,omitempty" mapstructure:"@cani.id"`
	CaniLastModified     string      `json:"@cani.lastModified,omitempty" mapstructure:"@cani.lastModified"`
	CaniSlsSchemaVersion string      `json:"@cani.slsSchemaVersion,omitempty" mapstructure:"@cani.slsSchemaVersion"`
	CaniStatus           *CaniStatus `json:"@cani.status,omitempty" mapstructure:"@cani.status"`
	IP6addr              string      `json:"IP6addr,omitempty" mapstructure:"IP6addr"`
	IP4addr              string      `json:"IP4addr,omitempty" mapstructure:"IP4addr"`
	Brand                string      `json:"Brand,omitempty" mapstructure:"Brand"`
	Model                string      `json:"Model,omitempty" mapstructure:"Model"`
	SNMPAuthPassword     string      `json:"SNMPAuthPassword,omitempty" mapstructure:"SNMPAuthPassword"`
	SNMPAuthProtocol     string      `json:"SNMPAuthProtocol,omitempty" mapstructure:"SNMPAuthProtocol"`
	SNMPPrivPassword     string      `json:"SNMPPrivPassword,omitempty" mapstructure:"SNMPPrivPassword"`
	SNMPPrivProtocol     string      `json:"SNMPPrivProtocol,omitempty" mapstructure:"SNMPPrivProtocol"`
	SNMPUsername         string      `json:"SNMPUsername,omitempty" mapstructure:"SNMPUsername"`
	Aliases              []string    `json:"Aliases,omitempty" mapstructure:"Aliases"`
}

type HardwareExtraPropertiesMgmtSwitch ¶

type HardwareExtraPropertiesMgmtSwitch struct {
	CaniId               string      `json:"@cani.id,omitempty" mapstructure:"@cani.id"`
	CaniLastModified     string      `json:"@cani.lastModified,omitempty" mapstructure:"@cani.lastModified"`
	CaniSlsSchemaVersion string      `json:"@cani.slsSchemaVersion,omitempty" mapstructure:"@cani.slsSchemaVersion"`
	CaniStatus           *CaniStatus `json:"@cani.status,omitempty" mapstructure:"@cani.status"`
	IP6addr              string      `json:"IP6addr,omitempty" mapstructure:"IP6addr"`
	IP4addr              string      `json:"IP4addr,omitempty" mapstructure:"IP4addr"`
	Brand                string      `json:"Brand,omitempty" mapstructure:"Brand"`
	Model                string      `json:"Model,omitempty" mapstructure:"Model"`
	SNMPAuthPassword     string      `json:"SNMPAuthPassword,omitempty" mapstructure:"SNMPAuthPassword"`
	SNMPAuthProtocol     string      `json:"SNMPAuthProtocol,omitempty" mapstructure:"SNMPAuthProtocol"`
	SNMPPrivPassword     string      `json:"SNMPPrivPassword,omitempty" mapstructure:"SNMPPrivPassword"`
	SNMPPrivProtocol     string      `json:"SNMPPrivProtocol,omitempty" mapstructure:"SNMPPrivProtocol"`
	SNMPUsername         string      `json:"SNMPUsername,omitempty" mapstructure:"SNMPUsername"`
	Aliases              []string    `json:"Aliases,omitempty" mapstructure:"Aliases"`
}

type HardwareExtraPropertiesMgmtSwitchConnector ¶

type HardwareExtraPropertiesMgmtSwitchConnector struct {
	CaniId               string      `json:"@cani.id,omitempty" mapstructure:"@cani.id"`
	CaniLastModified     string      `json:"@cani.lastModified,omitempty" mapstructure:"@cani.lastModified"`
	CaniSlsSchemaVersion string      `json:"@cani.slsSchemaVersion,omitempty" mapstructure:"@cani.slsSchemaVersion"`
	CaniStatus           *CaniStatus `json:"@cani.status,omitempty" mapstructure:"@cani.status"`
	// An array of xnames that the hardware_mgmt_switch_connector is connected to.  Excludes the parent.
	NodeNics []string `json:"NodeNics" mapstructure:"NodeNics"`
	// The vendor-assigned name for this port, as it appears in the switch management software.  Typically this is something like \"GigabitEthernet 1/31\" (Berkeley-style names), but may be any string.
	VendorName string `json:"VendorName,omitempty" mapstructure:"VendorName"`
}

type HardwareExtraPropertiesNcard ¶

type HardwareExtraPropertiesNcard struct {
	CaniId               string      `json:"@cani.id,omitempty" mapstructure:"@cani.id"`
	CaniLastModified     string      `json:"@cani.lastModified,omitempty" mapstructure:"@cani.lastModified"`
	CaniSlsSchemaVersion string      `json:"@cani.slsSchemaVersion,omitempty" mapstructure:"@cani.slsSchemaVersion"`
	CaniStatus           *CaniStatus `json:"@cani.status,omitempty" mapstructure:"@cani.status"`
	// The ipv6 address that should be assigned to this BMC, or \"DHCPv6\".  If omitted, \"DHCPv6\" is assumed.
	IP6addr string `json:"IP6addr,omitempty" mapstructure:"IP6addr"`
	// The ipv4 address that should be assigned to this BMC, or \"DHCPv4\".  If omitted, \"DHCPv4\" is assumed.
	IP4addr string `json:"IP4addr,omitempty" mapstructure:"IP4addr"`
	// The username that should be used to access the device (or be assigned to the device)
	Username string `json:"Username,omitempty" mapstructure:"Username"`
	// The password that should be used to access the device (or be assigned to the device)
	Password string `json:"Password,omitempty" mapstructure:"Password"`
}

type HardwareExtraPropertiesNode ¶

type HardwareExtraPropertiesNode struct {
	CaniId               string      `json:"@cani.id,omitempty" mapstructure:"@cani.id"`
	CaniLastModified     string      `json:"@cani.lastModified,omitempty" mapstructure:"@cani.lastModified"`
	CaniSlsSchemaVersion string      `json:"@cani.slsSchemaVersion,omitempty" mapstructure:"@cani.slsSchemaVersion"`
	CaniStatus           *CaniStatus `json:"@cani.status,omitempty" mapstructure:"@cani.status"`
	NID                  int32       `json:"NID,omitempty" mapstructure:"NID"`
	Role                 string      `json:"Role" mapstructure:"Role"`
	SubRole              string      `json:"SubRole,omitempty" mapstructure:"SubRole"`
	Aliases              []string    `json:"Aliases" mapstructure:"Aliases"`
}

type HardwareExtraPropertiesNodeHsnNic ¶

type HardwareExtraPropertiesNodeHsnNic struct {
	CaniId               string      `json:"@cani.id,omitempty" mapstructure:"@cani.id"`
	CaniLastModified     string      `json:"@cani.lastModified,omitempty" mapstructure:"@cani.lastModified"`
	CaniSlsSchemaVersion string      `json:"@cani.slsSchemaVersion,omitempty" mapstructure:"@cani.slsSchemaVersion"`
	CaniStatus           *CaniStatus `json:"@cani.status,omitempty" mapstructure:"@cani.status"`
	// An array of network names that this NIC is connected to
	Networks []string `json:"Networks" mapstructure:"Networks"`
	// An array of xnames this NIC is connected directly to.  These ideally connector xnames, not switches
	Peers []string `json:"Peers" mapstructure:"Peers"`
}

type HardwareExtraPropertiesNodeNic ¶

type HardwareExtraPropertiesNodeNic struct {
	CaniId               string      `json:"@cani.id,omitempty" mapstructure:"@cani.id"`
	CaniLastModified     string      `json:"@cani.lastModified,omitempty" mapstructure:"@cani.lastModified"`
	CaniSlsSchemaVersion string      `json:"@cani.slsSchemaVersion,omitempty" mapstructure:"@cani.slsSchemaVersion"`
	CaniStatus           *CaniStatus `json:"@cani.status,omitempty" mapstructure:"@cani.status"`
	// An array of network names that this NIC is connected to
	Networks []string `json:"Networks" mapstructure:"Networks"`
	// An array of xnames this NIC is connected directly to.  These ideally connector xnames, not switches
	Peers []string `json:"Peers" mapstructure:"Peers"`
}

type HardwareExtraPropertiesRtrBmc ¶

type HardwareExtraPropertiesRtrBmc struct {
	CaniId               string      `json:"@cani.id,omitempty" mapstructure:"@cani.id"`
	CaniLastModified     string      `json:"@cani.lastModified,omitempty" mapstructure:"@cani.lastModified"`
	CaniSlsSchemaVersion string      `json:"@cani.slsSchemaVersion,omitempty" mapstructure:"@cani.slsSchemaVersion"`
	CaniStatus           *CaniStatus `json:"@cani.status,omitempty" mapstructure:"@cani.status"`
	// The ipv6 address that should be assigned to this BMC, or \"DHCPv6\".  If omitted, \"DHCPv6\" is assumed.
	IP6addr string `json:"IP6addr" mapstructure:"IP6addr"`
	// The ipv4 address that should be assigned to this BMC, or \"DHCPv4\".  If omitted, \"DHCPv4\" is assumed.
	IP4addr string `json:"IP4addr" mapstructure:"IP4addr"`
	// The username that should be used to access the device (or be assigned to the device)
	Username string `json:"Username,omitempty" mapstructure:"Username"`
	// The password that should be used to access the device (or be assigned to the device)
	Password string `json:"Password,omitempty" mapstructure:"Password"`
}

type HardwareExtraPropertiesRtrBmcNic ¶

type HardwareExtraPropertiesRtrBmcNic struct {
	CaniId               string      `json:"@cani.id,omitempty" mapstructure:"@cani.id"`
	CaniLastModified     string      `json:"@cani.lastModified,omitempty" mapstructure:"@cani.lastModified"`
	CaniSlsSchemaVersion string      `json:"@cani.slsSchemaVersion,omitempty" mapstructure:"@cani.slsSchemaVersion"`
	CaniStatus           *CaniStatus `json:"@cani.status,omitempty" mapstructure:"@cani.status"`
	// An array of network names that this NIC is connected to
	Networks []string `json:"Networks" mapstructure:"Networks"`
	// An array of xnames this NIC is connected directly to.  These ideally connector xnames, not switches
	Peers []string `json:"Peers" mapstructure:"Peers"`
}

type HardwareExtraPropertiesRtrmod ¶

type HardwareExtraPropertiesRtrmod struct {
	CaniId               string      `json:"@cani.id,omitempty" mapstructure:"@cani.id"`
	CaniLastModified     string      `json:"@cani.lastModified,omitempty" mapstructure:"@cani.lastModified"`
	CaniSlsSchemaVersion string      `json:"@cani.slsSchemaVersion,omitempty" mapstructure:"@cani.slsSchemaVersion"`
	CaniStatus           *CaniStatus `json:"@cani.status,omitempty" mapstructure:"@cani.status"`
	// An array of xnames, where each xname has type==*_pwr_connector.  Empty for Mountain switch cards
	PowerConnector []string `json:"PowerConnector" mapstructure:"PowerConnector"`
}

type HardwareExtraPropertiesSystem ¶

type HardwareExtraPropertiesSystem struct {
	CaniLastModified     string      `json:"@cani.lastModified,omitempty" mapstructure:"@cani.lastModified"`
	CaniSlsSchemaVersion string      `json:"@cani.slsSchemaVersion,omitempty" mapstructure:"@cani.slsSchemaVersion"`
	CaniId               string      `json:"@cani.id,omitempty" mapstructure:"@cani.id"`
	CaniStatus           *CaniStatus `json:"@cani.status,omitempty" mapstructure:"@cani.status"`
}

type HardwareIpAndCredsOptional ¶

type HardwareIpAndCredsOptional struct {
	// The ipv6 address that should be assigned to this BMC, or \"DHCPv6\".  If omitted, \"DHCPv6\" is assumed.
	IP6addr string `json:"IP6addr,omitempty"`
	// The ipv4 address that should be assigned to this BMC, or \"DHCPv4\".  If omitted, \"DHCPv4\" is assumed.
	IP4addr string `json:"IP4addr,omitempty"`
	// The username that should be used to access the device (or be assigned to the device)
	Username string `json:"Username,omitempty"`
	// The password that should be used to access the device (or be assigned to the device)
	Password string `json:"Password,omitempty"`
}

type HardwareNic ¶

type HardwareNic struct {
	// An array of network names that this NIC is connected to
	Networks []string `json:"Networks"`
	// An array of xnames this NIC is connected directly to.  These ideally connector xnames, not switches
	Peers []string `json:"Peers"`
}

type HardwarePost ¶

type HardwarePost struct {
	Xname           string                   `json:"Xname" mapstructure:"Xname"`
	Class           *HardwareClass           `json:"Class" mapstructure:"Class"`
	ExtraProperties *HardwareExtraProperties `json:"ExtraProperties,omitempty" mapstructure:"ExtraProperties"`
}

type HardwarePoweredDevice ¶

type HardwarePoweredDevice struct {
	// An array of xnames, where each xname has type==*_pwr_connector.  Empty for Mountain switch cards
	PowerConnector []string `json:"PowerConnector"`
}

type HardwarePut ¶

type HardwarePut struct {
	Class           *HardwareClass           `json:"Class" mapstructure:"Class"`
	ExtraProperties *HardwareExtraProperties `json:"ExtraProperties,omitempty" mapstructure:"ExtraProperties"`
}

type HardwarePwrConnector ¶

type HardwarePwrConnector struct {
	PoweredBy string `json:"PoweredBy"`
}

type HardwareType ¶

type HardwareType string

HardwareType : The type of this piece of hardware. This is an optional hint during upload; it will be ignored if it does not match the xname

const (
	CDU_HardwareType                     HardwareType = "comptype_cdu"
	CDU_MGMT_SWITCH_HardwareType         HardwareType = "comptype_cdu_mgmt_switch"
	CAB_CDU_HardwareType                 HardwareType = "comptype_cab_cdu"
	CABINET_HardwareType                 HardwareType = "comptype_cabinet"
	CAB_PDU_CONTROLLER_HardwareType      HardwareType = "comptype_cab_pdu_controller"
	CAB_PDU_HardwareType                 HardwareType = "comptype_cab_pdu"
	CAB_PDU_NIC_HardwareType             HardwareType = "comptype_cab_pdu_nic"
	CAB_PDU_OUTLET_HardwareType          HardwareType = "comptype_cab_pdu_outlet"
	CAB_PDU_PWR_CONNECTOR_HardwareType   HardwareType = "comptype_cab_pdu_pwr_connector"
	CHASSIS_HardwareType                 HardwareType = "comptype_chassis"
	CHASSIS_BMC_HardwareType             HardwareType = "comptype_chassis_bmc"
	CMM_RECTIFIER_HardwareType           HardwareType = "comptype_cmm_rectifier"
	CMM_FPGA_HardwareType                HardwareType = "comptype_cmm_fpga"
	CEC_HardwareType                     HardwareType = "comptype_cec"
	COMPMOD_HardwareType                 HardwareType = "comptype_compmod"
	RTRMOD_HardwareType                  HardwareType = "comptype_rtrmod"
	NCARD_HardwareType                   HardwareType = "comptype_ncard"
	BMC_NIC_HardwareType                 HardwareType = "comptype_bmc_nic"
	NODE_ENCLOSURE_HardwareType          HardwareType = "comptype_node_enclosure"
	COMPMOD_POWER_CONNECTOR_HardwareType HardwareType = "comptype_compmod_power_connector"
	NODE_HardwareType                    HardwareType = "comptype_node"
	NODE_PROCESSOR_HardwareType          HardwareType = "comptype_node_processor"
	NODE_NIC_HardwareType                HardwareType = "comptype_node_nic"
	NODE_HSN_NIC_HardwareType            HardwareType = "comptype_node_hsn_nic"
	DIMM_HardwareType                    HardwareType = "comptype_dimm"
	NODE_ACCEL_HardwareType              HardwareType = "comptype_node_accel"
	NODE_FPGA_HardwareType               HardwareType = "comptype_node_fpga"
	HSN_ASIC_HardwareType                HardwareType = "comptype_hsn_asic"
	RTR_FPGA_HardwareType                HardwareType = "comptype_rtr_fpga"
	RTR_TOR_FPGA_HardwareType            HardwareType = "comptype_rtr_tor_fpga"
	RTR_BMC_HardwareType                 HardwareType = "comptype_rtr_bmc"
	RTR_BMC_NIC_HardwareType             HardwareType = "comptype_rtr_bmc_nic"
	HSN_BOARD_HardwareType               HardwareType = "comptype_hsn_board"
	HSN_LINK_HardwareType                HardwareType = "comptype_hsn_link"
	HSN_CONNECTOR_HardwareType           HardwareType = "comptype_hsn_connector"
	HSN_CONNECTOR_PORT_HardwareType      HardwareType = "comptype_hsn_connector_port"
	MGMT_SWITCH_HardwareType             HardwareType = "comptype_mgmt_switch"
	MGMT_SWITCH_CONNECTOR_HardwareType   HardwareType = "comptype_mgmt_switch_connector"
	HL_SWITCH_HardwareType               HardwareType = "comptype_hl_switch"
)

List of hardware_type

type InlineResponse200 ¶

type InlineResponse200 struct {
	// Status of the Vault.
	Vault string `json:"Vault" mapstructure:"Vault"`
	// Status of the connection with the database.
	DBConnection string `json:"DBConnection" mapstructure:"DBConnection"`
}

type LoadstateBody ¶

type LoadstateBody struct {
	SlsDump *SlsState `json:"sls_dump,omitempty" mapstructure:"sls_dump"`
}

type MiscApiService ¶

type MiscApiService service

func (*MiscApiService) HealthGet ¶

func (a *MiscApiService) HealthGet(ctx context.Context) (InlineResponse200, *http.Response, error)

MiscApiService Query the health of the service The `health` resource returns health information about the SLS service and its dependencies. This actively checks the connection between SLS and the following: * Vault * Database This is primarily intended as a diagnostic tool to investigate the functioning of the SLS service.

@param ctx context.Context - for authentication, logging, cancellation, deadlines, tracing, etc. Passed from http.Request or context.Background().

@return InlineResponse200

func (*MiscApiService) LivenessGet ¶

func (a *MiscApiService) LivenessGet(ctx context.Context) (*http.Response, error)

MiscApiService Kubernetes liveness endpoint to monitor service health The `liveness` resource works in conjunction with the Kubernetes liveness probe to determine when the service is no longer responding to requests. Too many failures of the liveness probe will result in the service being shut down and restarted. This is primarily an endpoint for the automated Kubernetes system.

@param ctx context.Context - for authentication, logging, cancellation, deadlines, tracing, etc. Passed from http.Request or context.Background().

func (*MiscApiService) ReadinessGet ¶

func (a *MiscApiService) ReadinessGet(ctx context.Context) (*http.Response, error)

MiscApiService Kubernetes readiness endpoint to monitor service health The `readiness` resource works in conjunction with the Kubernetes readiness probe to determine when the service is no longer healthy and able to respond correctly to requests. Too many failures of the readiness probe will result in the traffic being routed away from this service and eventually the service will be shut down and restarted if in an unready state for too long. This is primarily an endpoint for the automated Kubernetes system.

@param ctx context.Context - for authentication, logging, cancellation, deadlines, tracing, etc. Passed from http.Request or context.Background().

func (*MiscApiService) VersionGet ¶

func (a *MiscApiService) VersionGet(ctx context.Context) (VersionResponse, *http.Response, error)

MiscApiService Retrieve versioning information on the information in SLS Retrieve the current version of the SLS mapping. Information returned is a JSON array with two keys: * Counter: A monotonically increasing counter. This counter is incremented every time a change is made to the map stored in SLS. This shall be 0 if no data is uploaded to SLS * LastUpdated: An ISO 8601 datetime representing the time of the last change to SLS. This shall be set to the Unix Epoch if no data has ever been stored in SLS.

@param ctx context.Context - for authentication, logging, cancellation, deadlines, tracing, etc. Passed from http.Request or context.Background().

@return VersionResponse

type Network ¶

type Network struct {
	Name            string                  `json:"Name" mapstructure:"Name"`
	FullName        string                  `json:"FullName" mapstructure:"FullName"`
	IPRanges        []string                `json:"IPRanges" mapstructure:"IPRanges"`
	Type_           string                  `json:"Type" mapstructure:"Type"`
	LastUpdated     int32                   `json:"LastUpdated,omitempty" mapstructure:"LastUpdated"`
	LastUpdatedTime string                  `json:"LastUpdatedTime,omitempty" mapstructure:"LastUpdatedTime"`
	ExtraProperties *NetworkExtraProperties `json:"ExtraProperties" mapstructure:"ExtraProperties"`
}

type NetworkApiNetworksNetworkPutOpts ¶

type NetworkApiNetworksNetworkPutOpts struct {
	Body optional.Interface
}

type NetworkApiNetworksPostOpts ¶

type NetworkApiNetworksPostOpts struct {
	Body optional.Interface
}

type NetworkApiService ¶

type NetworkApiService service

func (*NetworkApiService) NetworksGet ¶

func (a *NetworkApiService) NetworksGet(ctx context.Context) ([]Network, *http.Response, error)

NetworkApiService Retrieve a list of networks in the system Retrieve a JSON list of the networks available in the system. Return value is an array of strings with each string representing the name field of the network object.

@param ctx context.Context - for authentication, logging, cancellation, deadlines, tracing, etc. Passed from http.Request or context.Background().

@return []Network

func (*NetworkApiService) NetworksNetworkDelete ¶

func (a *NetworkApiService) NetworksNetworkDelete(ctx context.Context, network string) (*http.Response, error)

NetworkApiService Delete the named network Delete the specific network from SLS.

@param ctx context.Context - for authentication, logging, cancellation, deadlines, tracing, etc. Passed from http.Request or context.Background().
@param network The network to look up or alter.

func (*NetworkApiService) NetworksNetworkGet ¶

func (a *NetworkApiService) NetworksNetworkGet(ctx context.Context, network string) (Network, *http.Response, error)

NetworkApiService Retrieve a network item Retrieve the specific network.

@param ctx context.Context - for authentication, logging, cancellation, deadlines, tracing, etc. Passed from http.Request or context.Background().
@param network The network to look up or alter.

@return Network

func (*NetworkApiService) NetworksNetworkPut ¶

func (a *NetworkApiService) NetworksNetworkPut(ctx context.Context, network string, localVarOptionals *NetworkApiNetworksNetworkPutOpts) (Network, *http.Response, error)

func (*NetworkApiService) NetworksPost ¶

func (a *NetworkApiService) NetworksPost(ctx context.Context, localVarOptionals *NetworkApiNetworksPostOpts) (*http.Response, error)

type NetworkExtraProperties ¶

type NetworkExtraProperties struct {
	CIDR      string              `json:"CIDR" mapstructure:"CIDR"`
	VlanRange []int32             `json:"VlanRange" mapstructure:"VlanRange"`
	MTU       int32               `json:"MTU" mapstructure:"MTU"`
	Subnets   []NetworkIpv4Subnet `json:"Subnets" mapstructure:"Subnets"`
	Comment   string              `json:"Comment,omitempty" mapstructure:"Comment"`
}

type NetworkIpReservation ¶

type NetworkIpReservation struct {
	IPAddress string   `json:"IPAddress" mapstructure:"IPAddress"`
	Name      string   `json:"Name" mapstructure:"Name"`
	Aliases   []string `json:"Aliases,omitempty" mapstructure:"Aliases"`
	Comment   string   `json:"Comment,omitempty" mapstructure:"Comment"`
}

type NetworkIpv4Subnet ¶

type NetworkIpv4Subnet struct {
	Name           string                 `json:"Name" mapstructure:"Name"`
	FullName       string                 `json:"FullName" mapstructure:"FullName"`
	CIDR           string                 `json:"CIDR" mapstructure:"CIDR"`
	VlanID         int32                  `json:"VlanID" mapstructure:"VlanID"`
	Gateway        string                 `json:"Gateway" mapstructure:"Gateway"`
	DHCPStart      string                 `json:"DHCPStart,omitempty" mapstructure:"DHCPStart"`
	DHCPEnd        string                 `json:"DHCPEnd,omitempty" mapstructure:"DHCPEnd"`
	IPReservations []NetworkIpReservation `json:"IPReservations,omitempty" mapstructure:"IPReservations"`
	Comment        string                 `json:"Comment,omitempty" mapstructure:"Comment"`
}

type Problem7807 ¶

type Problem7807 struct {
	Type_    string  `json:"type" mapstructure:"type"`
	Detail   string  `json:"detail,omitempty" mapstructure:"detail"`
	Instance string  `json:"instance,omitempty" mapstructure:"instance"`
	Status   float64 `json:"status,omitempty" mapstructure:"status"`
	Title    string  `json:"title,omitempty" mapstructure:"title"`
}

RFC 7807 compliant error payload. All fields are optional except the 'type' field.

type SearchApiSearchHardwareGetOpts ¶

type SearchApiSearchHardwareGetOpts struct {
	Xname          optional.Interface
	Parent         optional.Interface
	Class          optional.Interface
	Type_          optional.Interface
	PowerConnector optional.Interface
	Object         optional.Interface
	NodeNics       optional.Interface
	Networks       optional.String
	Peers          optional.Interface
}

type SearchApiSearchNetworksGetOpts ¶

type SearchApiSearchNetworksGetOpts struct {
	Name      optional.String
	FullName  optional.String
	Type_     optional.Interface
	IpAddress optional.Interface
}

type SearchApiService ¶

type SearchApiService service

func (*SearchApiService) SearchHardwareGet ¶

func (a *SearchApiService) SearchHardwareGet(ctx context.Context, localVarOptionals *SearchApiSearchHardwareGetOpts) ([]Hardware, *http.Response, error)

func (*SearchApiService) SearchNetworksGet ¶

func (a *SearchApiService) SearchNetworksGet(ctx context.Context, localVarOptionals *SearchApiSearchNetworksGetOpts) ([]Network, *http.Response, error)

type SlsState ¶

type SlsState struct {
	Hardware map[string]Hardware `json:"Hardware,omitempty" mapstructure:"Hardware"`
	Networks map[string]Network  `json:"Networks,omitempty" mapstructure:"Networks"`
}

type VersionResponse ¶

type VersionResponse struct {
	// A monotonically increasing counter that increases every time a change is made to SLS
	Counter int32 `json:"counter,omitempty" mapstructure:"counter"`
	// An ISO-8601 datetime representing when a change was last made to SLS
	LastUpdated time.Time `json:"last_updated,omitempty" mapstructure:"last_updated"`
}

Source Files ¶

View all Source files

?	: This menu
/	: Search site
f or F	: Jump to
y or Y	: Canonical URL