Application Package Reference

edit page

This is the application package reference. An application package is the deployment unit in Vespa. To deploy an application, create an application package and vespa-deploy it - refer to application packages. The application package consists of a directory of files and subdirectories:

Directory/file	Description	Required
[application]/	The top level directory is the name of the application	Yes
[application]/services.xml	Describes which services to run where, and their main configuration	Yes
[application]/validation-overrides.xml	Override, allowing this package to deploy even if it fails validation	No
[application]/models/	Machine-learned models in the application package. See Tensorflow, Onnx and XGBoost	No
[application]/searchdefinitions/	Contains the *.sd files describing the document types of the application and how they should be searched	No
[application]/components/	Contains *.jar files containing searcher(s) for the JDisc Container.	No
[application]/rules/	Contains *.sr files containing rule bases for semantic recognition and translation of the query	No
[application]/search/	Search chains config	No
[application]/constants/	Constant tensors	No
[application]/ext/	Files that are guaranteed to be ignored by Vespa (i.e. they will be excluded when processing the application package and cannot be referenced from any other place in the application package)	No
[application]/hosts.xml	The mapping from logical nodes to actual hosts	No

Additional files and directories can be placed anywhere in the application package. These will be not be processed explicitly by Vespa when deploying the application package (i.e., they will only be considered if they are referred to from within the application package), but there is no guarantee to how these might be processed in a future release. To extend the application package in a way that is guaranteed to be ignored by Vespa in all future releases, use the [application]/ext/ directory.

Versioning application packages

An application can be given a user-defined version, available at /ApplicationStatus view. Configure the version in services.xml (at top level):

<services>
  <config name="container.handler.observability.application-userdata">
    <version>42</version>
  </config>
  ...
</services>

Preprocess directives

Preprocess directives is used to:

• preprocess:properties: define properties that one can refer to everywhere in services.xml
• preprocess:include: split services.xml in smaller chunks

In the below example, ${container.port} will be replaced by 4099. The contents of content.xml is placed at the include point. This is applied recursively, one can use preprocess directives in included files as long as namespaces are defined in the top level file:

<services version="1.0" xmlns:preprocess="properties">
  <preprocess:properties>
      <container.port>4099</container.port>
  </preprocess:properties>
  <container version="1.0">
      <http>
        <server id="container" port="${container.port}" />
      </http>
      <search />
  </container>
    <preprocess:include file="content.xml" />
</services>

Sample content.xml:

<content version="1.0" >
  <redundancy>1</redundancy>
  <documents>
    <document type="music.sd" mode="index" />
  </documents>
  <nodes>
    <node hostalias="node0"/>
    <node hostalias="node1"/>
    <node hostalias="node2"/>
  </nodes>
  
</content>