Manage remotes via API

Is there or is there plans to add remotes endpoint to the API? Or was it left out for a reason?

Just throwing it out there…

I think this would be a great feature as it would allow for roll your own clustering for container load balancing and many other things like managing remotes through remotes without needing to store secrets or a list of remotes within the interface.

Adding a remote would be like CLI you supply the secret, upon adding it the server maintains a client PEM certificate as if you called POST /1.0/certificates and added it, so much like that endpoint but giving information about the list of remotes currently set on the server.

So the API would look something like:

/1.0/remote

GET

  • Description: List of remotes
  • Authentication: trusted
  • Operation: sync
  • Return: list of URLs for remotes this server publishes

Return value:

[
    "/1.0/remote/images",
    "/1.0/remote/local",
    "/1.0/remote/ubuntu",
    "/1.0/remote/ubuntu-daily"
]

POST

  • Description: Create a new remote
  • Authentication: trusted
  • Operation: async
  • Return: background operation or standard error

Input:

{
    "name": "my-remote",
    "url": "https://lxd.example.com:8443", #<IP|FQDN|URL>
    "secret": "secret-password",
    "protocol": "lxd",
    "auth-type": "tls or macaroons",
    "public": false,
    "static": true,
    "default": false
}

Output:

{
    "type": "client",
    "certificate": "PEM certificate",
    "name": "my-remote",
    "fingerprint": "SHA256 Hash of the raw certificate"
}

Then sub-process automatically creates client certificate as if POST /1.0/certificates was done using secret.

/1.0/remote/<name>

GET

  • Description: Remote information
  • Authentication: trusted
  • Operation: sync
  • Return: dict of the remote configuration and current state.

Output (private):

{
    "name": "my-remote",
    "url": "https://lxd.example.com:8443", #<IP|FQDN|URL>
    "certificate": "PEM certificate",
    "protocol": "lxd",
    "auth-type": "tls",
    "public": false,
    "static": true,
    "default": false
}

Output (local):

{
    "name": "local",
    "url": "unix://",
    "certificate": "",
    "protocol": "lxd",
    "auth-type": "tls",
    "public": false,
    "static": true,
    "default": true
}

Output (images):

{
    "name": "images",
    "url": "https://images.linuxcontainers.org",
    "certificate": "",
    "protocol": "simplestreams",
    "auth-type": "",
    "public": true,
    "static": false,
    "default": false
}

PUT (ETag supported)

  • Description: replaces remote configuration
  • Authentication: trusted
  • Operation: async
  • Return: background operation or standard error

Input (update replaces configuration):

{
    "url": "https://lxd.example.com:8443", #<IP|FQDN|URL>
    "protocol": "lxd",
    "auth-type": "tls",
    "public": false,
    "static": true,
    "default": false
}

Takes the same structure as that returned by GET but doesn’t allow name
changes (see POST below) or changes to the status sub-dict (since that’s
read-only).

PATCH (ETag supported)

  • Description: update remote configuration
  • Introduced: with API extension remote
  • Authentication: trusted
  • Operation: sync
  • Return: standard return value or standard error

Input:

{
    "url": "https://lxd.example.com:8443", #<IP|FQDN|URL>
    "protocol": "lxd",
    "auth-type": "tls or macaroons",
    "public": true,
    "static": true,
    "default": true
}

POST

  • Description: used to rename the remote
  • Authentication: trusted
  • Operation: async
  • Return: background operation or standard error

Renaming to an existing name must return the 409 (Conflict) HTTP code.

Input (simple rename):

{
    "name": "new-name"
}

DELETE

  • Description: remove the remote
  • Authentication: trusted
  • Operation: async
  • Return: background operation or standard error

Input (none at present):

{
}

I think that’s because remotes are a client-only concept.

Correct, as free said, there is no concept of remotes in the LXD daemon or its API.

Remotes are a client-only concept (so only the lxc command line tool) which lets you store URLs and certificates for a number of LXD servers to make it easier for the user to interact with several LXD hosts and image servers.