services.xml is the primary configuration file in an application package. Elements:
services [version] container [version] content [version] admin [version] routing [version]Nodes/hosts referred to in services.xml must be defined in hosts.xml using hostalias.
| Attribute | Required | Value | Default | Description |
|---|---|---|---|---|
| version | required | number | 1.0 in this version of Vespa |
Optional subelements (one or more of container, content or service is required):
Example:
<?xml version="1.0" encoding="utf-8" ?>
<services version="1.0">
<container version="1.0" id="container">
<search/>
<document-api/>
<nodes>
<node hostalias="node0"/>
</nodes>
</container>
<content id="music" version="1.0">
<redundancy>2</redundancy>
<nodes>
<node hostalias="node0"/>
<node hostalias="node1"/>
</nodes>
<documents>
<document type="music"/>
</documents>
</content>
</services>
Most elements in services.xml accept a sub-element named config. config elements can be included on different levels in the XML structure and the lower-level ones will override values in the higher-level ones (example below). The config element must include the attribute name, which gives the full name of the configuration option in question, including the namespace. The name can either refer to configuration definitions that are shipped with Vespa or ones that are part of the application package. For a complete example on generic configuration see the application package reference.
<container id="default" version="1.0">
<handler id="com.yahoo.vespatest.ConfiguredHandler">
<config name="vespatest.response">
<response>configured string</response>
</config>
</handler>
<nodes>
<node hostalias="node0"/>
</nodes>
</container>
Some features are configurable using XML files in subdirectories of the application package. This means that the configuration found in these XML files will be used as if it was inlined in services.xml. This is supported for search chains, docproc chains and routing tables.