Crate oxide_api

Expand description

A fully generated, opinionated API client library for Oxide.

§API Details

API for interacting with the Oxide control plane

§Contact

url	email
https://oxide.computer	api@oxide.computer

§Client Details

This client is generated from the Oxide OpenAPI specs based on API spec version 0.0.1. This way it will remain up to date as features are added. The documentation for the crate is generated along with the code to make this library easy to use.

To install the library, add the following to your Cargo.toml file.

[dependencies]
oxide-api = "0.1.0-rc.41"

§Basic example

Typical use will require intializing a Client. This requires a user agent string and set of credentials.

use oxide_api::Client;

let oxide = Client::new(String::from("api-key"), String::from("host"));

Alternatively, the library can search for most of the variables required for the client in the environment:

OXIDE_TOKEN
OXIDE_HOST

And then you can create a client from the environment.

use oxide_api::Client;

let oxide = Client::new_from_env();

Modules§

disks: Virtual disks are used to store instance-local data which includes the operating system.
hidden: TODO operations that will not ship to customers.
images: Images are read-only Virtual Disks that may be used to boot Virtual Machines.
images_global: Images are read-only Virtual Disks that may be used to boot Virtual Machines. These images are scoped globally.
instances: Virtual machine instances are the basic unit of computation. These operations are used for provisioning, controlling, and destroying instances.
ip_pools: IP Pools contain external IP addresses that can be assigned to virtual machine Instances.
login: Authentication endpoints.
metrics: Metrics provide insight into the operation of the Oxide deployment. These include telemetry on hardware and software components that can be used to understand the current state as well as to diagnose issues.
organizations: Organizations represent a subset of users and projects in an Oxide deployment.
policy: System-wide IAM policy.
projects: Projects are a grouping of associated resources such as instances and disks within an organization for purposes of billing and access control.
racks: These operations pertain to hardware inventory and management. Racks are the unit of expansion of an Oxide deployment. Racks are in turn composed of sleds, switches, power supplies, and a cabled backplane.
roles: Roles are a component of Identity and Access Management (IAM) that allow a user or agent account access to additional permissions.
routers: Routers direct the flow of network traffic into, out of, and within a VPC via routes.
routes: Routes define router policy.
sagas: Sagas are the abstraction used to represent multi-step operations within the Oxide deployment. These operations can be used to query saga status and report errors.
silos: Silos represent a logical partition of users and resources.
sleds: This tag should be moved into hardware.
snapshots: Snapshots of Virtual Disks at a particular point in time.
sshkeys: Public SSH keys for an individual user.
subnets: This tag should be moved into a generic network tag.
system: Internal system information.
types: The data types sent to and returned from the API client.
updates: This tag should be moved into a operations tag.
vpcs: A Virtual Private Cloud (VPC) is an isolated network environment that should probaby be moved into a more generic networking tag.

Structs§

Client: Entrypoint for interacting with the API client.