Documents Ganeti version 2.5
Contents
Ganeti supports a remote API for enable external tools to easily retrieve information about a cluster’s state. The remote API daemon, ganeti-rapi, is automatically started on the master node. By default it runs on TCP port 5080, but this can be changed either in .../constants.py or via the command line parameter -p. SSL mode, which is used by default, can also be disabled by passing command line parameters.
ganeti-rapi reads users and passwords from a file (usually /var/lib/ganeti/rapi/users) on startup. Changes to the file will be read automatically.
Each line consists of two or three fields separated by whitespace. The first two fields are for username and password. The third field is optional and can be used to specify per-user options. Currently, write is the only option supported and enables the user to execute operations modifying the cluster. Lines starting with the hash sign (#) are treated as comments.
Passwords can either be written in clear text or as a hash. Clear text passwords may not start with an opening brace ({) or they must be prefixed with {cleartext}. To use the hashed form, get the MD5 hash of the string $username:Ganeti Remote API:$password (e.g. echo -n 'jack:Ganeti Remote API:abc123' | openssl md5) [1] and prefix it with {ha1}. Using the scheme prefix for all passwords is recommended. Scheme prefixes are not case sensitive.
Example:
# Give Jack and Fred read-only access
jack abc123
fred {cleartext}foo555
# Give write access to an imaginary instance creation script
autocreator xyz789 write
# Hashed password for Jessica
jessica {HA1}7046452df2cbb530877058712cf17bd4 write
| [1] | Using the MD5 hash of username, realm and password is described in RFC 2617 (“HTTP Authentication”), sections 3.2.2.2 and 3.3. The reason for using it over another algorithm is forward compatibility. If ganeti-rapi were to implement HTTP Digest authentication in the future, the same hash could be used. In the current version ganeti-rapi‘s realm, Ganeti Remote API, can only be changed by modifying the source code. |
The protocol used is JSON over HTTP designed after the REST principle. HTTP Basic authentication as per RFC 2617 is supported.
HTTP requests with a body (e.g. PUT or POST) require the request header Content-type be set to application/json (see RFC 2616 (HTTP/1.1), section 7.2.1).
JSON as used by Ganeti RAPI does not conform to the specification in RFC 4627. Section 2 defines a JSON text to be either an object ({"key": "value", …}) or an array ([1, 2, 3, …]). In violation of this RAPI uses plain strings ("master-candidate", "1234") for some requests or responses. Changing this now would likely break existing clients and cause a lot of trouble.
Unlike Python’s JSON encoder and decoder, other programming languages or libraries may only provide a strict implementation, not allowing plain values. For those, responses can usually be wrapped in an array whose first element is then used, e.g. the response "1234" becomes ["1234"]. This works equally well for more complex values. Example in Ruby:
require "json"
# Insert code to get response here
response = "\"1234\""
decoded = JSON.parse("[#{response}]").first
Short of modifying the encoder to allow encoding to a less strict format, requests will have to be formatted by hand. Newer RAPI requests already use a dictionary as their input data and shouldn’t cause any problems.
According to RFC 2616 the main difference between PUT and POST is that POST can create new resources but PUT can only create the resource the URI was pointing to on the PUT request.
Unfortunately, due to historic reasons, the Ganeti RAPI library is not consistent with this usage, so just use the methods as documented below for each resource.
For more details have a look in the source code at lib/rapi/rlib2.py.
A few generic refered parameter types and the values they allow.
A few parameter mean the same thing across all resources which implement it.
Bulk-mode means that for the resources which usually return just a list of child resources (e.g. /2/instances which returns just instance names), the output will instead contain detailed data for all these subresources. This is more efficient than query-ing the sub-resources themselves.
The boolean dry-run argument, if provided and set, signals to Ganeti that the job should not be executed, only the pre-execution checks will be done.
This is useful in trying to determine (without guarantees though, as in the meantime the cluster state could have changed) if the operation is likely to succeed or at least start executing.
You can access the API using your favorite programming language as long as it supports network connections.
Ganeti includes a standalone RAPI client, lib/rapi/client.py.
Using wget:
wget -q -O - https://CLUSTERNAME:5080/2/info
or curl:
curl https://CLUSTERNAME:5080/2/info
Warning
While it’s possible to use JavaScript, it poses several potential problems, including browser blocking request due to non-standard ports or different domain names. Fetching the data on the webserver is easier.
var url = 'https://CLUSTERNAME:5080/2/info';
var info;
var xmlreq = new XMLHttpRequest();
xmlreq.onreadystatechange = function () {
if (xmlreq.readyState != 4) return;
if (xmlreq.status == 200) {
info = eval("(" + xmlreq.responseText + ")");
alert(info);
} else {
alert('Error fetching cluster info');
}
xmlreq = null;
};
xmlreq.open('GET', url, true);
xmlreq.send(null);
Cluster information resource.
It supports the following commands: GET.
Returns cluster information.
Example:
{
"config_version": 2000000,
"name": "cluster",
"software_version": "2.0.0~beta2",
"os_api_version": 10,
"export_version": 0,
"candidate_pool_size": 10,
"enabled_hypervisors": [
"fake"
],
"hvparams": {
"fake": {}
},
"default_hypervisor": "fake",
"master": "node1.example.com",
"architecture": [
"64bit",
"x86_64"
],
"protocol_version": 20,
"beparams": {
"default": {
"auto_balance": true,
"vcpus": 1,
"memory": 128
}
}
}
Redistribute configuration to all nodes.
It supports the following commands: PUT.
Returns a list of features supported by the RAPI server. Available features:
Modifies cluster parameters.
Supports the following commands: PUT.
Returns a job ID.
Body parameters:
The groups resource.
It supports the following commands: GET, POST.
Returns a list of all existing node groups.
Example:
[
{
"name": "group1",
"uri": "\/2\/groups\/group1"
},
{
"name": "group2",
"uri": "\/2\/groups\/group2"
}
]
If the optional bool bulk argument is provided and set to a true value (i.e ?bulk=1), the output contains detailed information about node groups as a list.
Returned fields: alloc_policy, ctime, mtime, name, node_cnt, node_list, serial_no, tags, uuid
Example:
[
{
"name": "group1",
"node_cnt": 2,
"node_list": [
"node1.example.com",
"node2.example.com"
],
"uuid": "0d7d407c-262e-49af-881a-6a430034bf43"
},
{
"name": "group2",
"node_cnt": 1,
"node_list": [
"node3.example.com"
],
"uuid": "f5a277e7-68f9-44d3-a378-4b25ecb5df5c"
}
]
Creates a node group.
If the optional bool dry-run argument is provided, the job will not be actually executed, only the pre-execution checks will be done.
Returns: a job ID that can be used later for polling.
Body parameters:
Earlier versions used a parameter named name which, while still supported, has been renamed to group_name.
Returns information about a node group.
It supports the following commands: GET, DELETE.
Modifies the parameters of a node group.
Supports the following commands: PUT.
Returns a job ID.
Body parameters:
Job result:
List of ((Length 2) and (Item 0 is (NonEmptyString [name of changed parameter]), item 1 is Anything))
Assigns nodes to a group.
Supports the following commands: PUT.
Manages per-nodegroup tags.
Supports the following commands: GET, PUT, DELETE.
The instances resource.
It supports the following commands: GET, POST.
Returns a list of all available instances.
Example:
[
{
"name": "web.example.com",
"uri": "\/instances\/web.example.com"
},
{
"name": "mail.example.com",
"uri": "\/instances\/mail.example.com"
}
]
If the optional bool bulk argument is provided and set to a true value (i.e ?bulk=1), the output contains detailed information about instances as a list.
Returned fields: admin_state, beparams, ctime, custom_beparams, custom_hvparams, custom_nicparams, disk.sizes, disk_template, disk_usage, hvparams, mtime, name, network_port, nic.bridges, nic.ips, nic.links, nic.macs, nic.modes, oper_ram, oper_state, oper_vcpus, os, pnode, serial_no, snodes, status, tags, uuid
Example:
[
{
"status": "running",
"disk_usage": 20480,
"nic.bridges": [
"xen-br0"
],
"name": "web.example.com",
"tags": ["tag1", "tag2"],
"beparams": {
"vcpus": 2,
"memory": 512
},
"disk.sizes": [
20480
],
"pnode": "node1.example.com",
"nic.macs": ["01:23:45:67:89:01"],
"snodes": ["node2.example.com"],
"disk_template": "drbd",
"admin_state": true,
"os": "debian-etch",
"oper_state": true
},
...
]
Creates an instance.
If the optional bool dry-run argument is provided, the job will not be actually executed, only the pre-execution checks will be done. Query-ing the job result will return, in both dry-run and normal case, the list of nodes selected for the instance.
Returns: a job ID that can be used later for polling.
Body parameters:
Earlier versions used parameters named name and os. These have been replaced by instance_name and os_type to match the underlying opcode. The old names can still be used.
Job result:
List of NonEmptyString [instance nodes]
Instance-specific resource.
It supports the following commands: GET, DELETE.
Returns information about an instance, similar to the bulk output from the instance list.
Returned fields: admin_state, beparams, ctime, custom_beparams, custom_hvparams, custom_nicparams, disk.sizes, disk_template, disk_usage, hvparams, mtime, name, network_port, nic.bridges, nic.ips, nic.links, nic.macs, nic.modes, oper_ram, oper_state, oper_vcpus, os, pnode, serial_no, snodes, status, tags, uuid
It supports the following commands: GET.
Reboots URI for an instance.
It supports the following commands: POST.
Reboots the instance.
The URI takes optional type=soft|hard|full and ignore_secondaries=0|1 parameters.
type defines the reboot type. soft is just a normal reboot, without terminating the hypervisor. hard means full shutdown (including terminating the hypervisor process) and startup again. full is like hard but also recreates the configuration from ground up as if you would have done a gnt-instance shutdown and gnt-instance start on it.
ignore_secondaries is a bool argument indicating if we start the instance even if secondary disks are failing.
It supports the dry-run argument.
Instance shutdown URI.
It supports the following commands: PUT.
Shutdowns an instance.
It supports the dry-run argument.
Instance startup URI.
It supports the following commands: PUT.
Installs the operating system again.
It supports the following commands: POST.
Returns a job ID.
Body parameters:
For backwards compatbility, this resource also takes the query parameters os (OS template name) and nostartup (bool). New clients should use the body parameters.
Replaces disks on an instance.
It supports the following commands: POST.
Returns a job ID.
Body parameters:
Ganeti 2.4 and below used query parameters. Those are deprecated and should no longer be used.
Activate disks on an instance.
It supports the following commands: PUT.
Deactivate disks on an instance.
It supports the following commands: PUT.
Grows one disk of an instance.
Supports the following commands: POST.
Prepares an export of an instance.
It supports the following commands: PUT.
Exports an instance.
It supports the following commands: PUT.
Returns a job ID.
Body parameters:
Migrates an instance.
Supports the following commands: PUT.
Returns a job ID.
Body parameters:
Does a failover of an instance.
Supports the following commands: PUT.
Returns a job ID.
Body parameters:
Renames an instance.
Supports the following commands: PUT.
Returns a job ID.
Body parameters:
Job result:
NonEmptyString [New instance name]
Modifies an instance.
Supports the following commands: PUT.
Returns a job ID.
Body parameters:
Job result:
List of ((Length 2) and (Item 0 is (NonEmptyString [name of changed parameter]), item 1 is Anything))
Request information for connecting to instance’s console.
Supports the following commands: GET.
Returns a dictionary containing information about the instance’s console. Contained keys:
Manages per-instance tags.
It supports the following commands: GET, PUT, DELETE.
The /2/jobs resource.
It supports the following commands: GET.
Returns a dictionary of jobs.
Returns: a dictionary with jobs id and uri.
If the optional bool bulk argument is provided and set to a true value (i.e. ?bulk=1), the output contains detailed information about jobs as a list.
Returned fields for bulk requests (unlike other bulk requests, these fields are not the same as for per-job requests): end_ts, id, ops, opstatus, received_ts, start_ts, status, summary
Individual job URI.
It supports the following commands: GET, DELETE.
Returns a dictionary with job parameters, containing the fields end_ts, id, oplog, opresult, ops, opstatus, received_ts, start_ts, status, summary.
The result includes:
For a successful opcode, the opresult field corresponding to it will contain the raw result from its LogicalUnit. In case an opcode has failed, its element in the opresult list will be a list of two elements:
The error classification is most useful for the OpPrereqError error type - these errors happen before the OpCode has started executing, so it’s possible to retry the OpCode without side effects. But whether it make sense to retry depends on the error classification:
Note that in the above list, by entity we refer to a node or instance, while by a resource we refer to an instance’s disk, or NIC, etc.
Waits for changes on a job. Takes the following body parameters in a dict:
Returns None if no changes have been detected and a dict with two keys, job_info and log_entries otherwise.
Nodes resource.
It supports the following commands: GET.
Returns a list of all nodes.
Example:
[
{
"id": "node1.example.com",
"uri": "\/nodes\/node1.example.com"
},
{
"id": "node2.example.com",
"uri": "\/nodes\/node2.example.com"
}
]
If the optional bool bulk argument is provided and set to a true value (i.e ?bulk=1), the output contains detailed information about nodes as a list.
Returned fields: cnodes, csockets, ctime, ctotal, dfree, drained, dtotal, group.uuid, master_candidate, master_capable, mfree, mnode, mtime, mtotal, name, offline, pinst_cnt, pinst_list, pip, role, serial_no, sinst_cnt, sinst_list, sip, tags, uuid, vm_capable
Example:
[
{
"pinst_cnt": 1,
"mfree": 31280,
"mtotal": 32763,
"name": "www.example.com",
"tags": [],
"mnode": 512,
"dtotal": 5246208,
"sinst_cnt": 2,
"dfree": 5171712,
"offline": false
},
...
]
Returns information about a node.
It supports the following commands: GET.
Returned fields: cnodes, csockets, ctime, ctotal, dfree, drained, dtotal, group.uuid, master_candidate, master_capable, mfree, mnode, mtime, mtotal, name, offline, pinst_cnt, pinst_list, pip, role, serial_no, sinst_cnt, sinst_list, sip, tags, uuid, vm_capable
Evacuates instances off a node.
It supports the following commands: POST.
Returns a job ID. The result of the job will contain the IDs of the individual jobs submitted to evacuate the node.
Body parameters:
Up to and including Ganeti 2.4 query arguments were used. Those are no longer supported. The new request can be detected by the presence of the node-evac-res1 feature string.
Job result:
Dictionary containing none but the required key "jobs" (value List of ((Length 2) and (Item 0 is (Boolean [success]), item 1 is (String or JobId [Job ID if successful, error message otherwise]))) [List of submitted jobs])
Migrates all primary instances from a node.
It supports the following commands: POST.
If no mode is explicitly specified, each instances’ hypervisor default migration mode will be used. Body parameters:
The query arguments used up to and including Ganeti 2.4 are deprecated and should no longer be used. The new request format can be detected by the presence of the node-migrate-reqv1 feature string.
Job result:
Dictionary containing none but the required key "jobs" (value List of ((Length 2) and (Item 0 is (Boolean [success]), item 1 is (String or JobId [Job ID if successful, error message otherwise]))) [List of submitted jobs])
Manages node role.
It supports the following commands: GET, PUT.
The role is always one of the following:
- drained
- master-candidate
- offline
- regular
Note that the ‘master’ role is a special, and currently it can’t be modified via RAPI, only via the command line (gnt-cluster master-failover).
Manages storage units on the node.
Modifies storage units on the node.
Repairs a storage unit on the node.
Manages per-node tags.
It supports the following commands: GET, PUT, DELETE.
Requests resource information. Available fields can be found in man pages and using /2/query/[resource]/fields. The resource is one of node, instance, group, os, lock. See the query2 design document for more details.
Supports the following commands: GET, PUT.
Request list of available fields for a resource. The resource is one of node, instance, group, os, lock. See the query2 design document for more details.
Supports the following commands: GET.