To build a multi-application system, use one or three config server(s) per application.
Best practise is using a containerized architecture,
also see multinode-HA.
The current API version is 2. The API port is 19071 - use
vespa-model-inspect service configserver
to find config server hosts. Example:
All operations are synchronous across the cluster of config servers,
meaning that requests return after the operations complete on all servers.
The session-id used in this API is generated by the server and is required
for all operations after creating a session.
The session is valid as long as it is one of the last 10 session-ids created.
An application file path in a request URL or parameter refers to a
relative path in the application package.
A path ending with "/" refers to a directory.
Creates a new session with the application package that is included in the request.
Should only be used when you want to create a session based on an active application.
Valid values are a URL to an active application.
A new session will be created based on the corresponding application.
Any errors or warnings from deleting the resource.
Prepares an application with the session-id given.
Name of the application to be deployed
Environment where application should be deployed
Region where application should be deployed
Name of application instance
If true, include stack trace in response if prepare fails.
Timeout in seconds to wait for session to be prepared.
Returns a session-id and a link to activate the session.
Log with any errors or warnings from preparing the application.
An activate URL for activating
the application with this session-id, if there were no errors.
A list of actions (possibly empty) that must be performed in order to apply some config changes
between the current active application and this next prepared application.
These actions are organized into three categories; restart, reindex, and refeed:
Restart actions are done after the application has been activated
and are handled by restarting all listed services.
schemas for details.
Returns a list of the currently active applications for the given tenant.
Returns a list of applications
Array of active applications
Gets info about the application.
Returns information about the application specified.
Returns reindexing status for the given application.
JSON detailing current reindexing status for the application, with all its clusters and document types.
Status for each content cluster in the application, by name:
Status of each document type in the cluster, by name:
Last time reindexing was triggered for this document type.
Current status of reindexing.
Optional start time of reindexing.
Optional end time of reindexing.
Optional progress of reindexing, from 0 to 1.
Triggers reindexing of specified document types in
specified clusters of an application.
Reindexing starts with the next redeployment of the application.
All document types in all clusters are reindexed unless restricted, using parameters as specified:
A comma-separated list of content clusters to limit reindexing to.
All clusters are reindexed if this is not present.
A comma-separated list of document types to limit reindexing to.
All document types are reindexed if this is not present.
Boolean: whether to trigger reindexing only for document types with indexing
mode index and at least one with field the indexing statement
index. Default is false.
Number (0-10], default 1: Relative indexing speed -
balance speed vs. resource use. Example: speed=0.1
A human-readable message indicating what reindexing was triggered.
Returns content at the given path for an application.
See getting content for usage and response.
Prepare the application with the URL in the prepared link from the response:
$ curl -s -X PUT "http://host:19071/application/v2/tenant/default/session/1/prepared?applicationName=default"
Activate the application with the URL in the activate link from the response:
$ curl -s -X PUT "http://host:19071/application/v2/tenant/default/session/1/active"
Modify the application package
Dump services.xml from session 1:
$ curl -s -X GET "http://host:19071/application/v2/tenant/default/session/1/content/services.xml"
Session 1 is activated and cannot be changed - create a new session based on the active session:
$ curl -s -X POST "http://host:19071/application/v2/tenant/default/session?from=http://host:19071/application/v2/tenant/default/application/default/environment/default/region/default/instance/default"
Modify rpcport to 12346 in services.xml, deploy the change:
$ curl -s -X PUT --data-binary @app/services.xml \
Get services.xml from session 2 to validate:
$ curl -s -X GET "http://host:19071/application/v2/tenant/default/session/2/content/services.xml"
To add the file files/test1.txt, first create the directory, then add the file:
$ curl -s -X PUT "http://host:19071/application/v2/tenant/default/session/2/content/files/"
$ curl -s -X PUT --data-binary @app/files/test1.txt \
Prepare and activate the session:
$ curl -s -X PUT "http://host:19071/application/v2/tenant/default/session/2/prepared?applicationName=fooapp"
$ curl -s -X PUT "http://host:19071/application/v2/tenant/default/session/2/active"
If you need to roll back to a previous version of the application package
this can be achieved by creating a new session based on the previous known
working version by passing the corresponding session-id in the
from argument, see creating a session