Developer Guide

Using Vespa Cloud for development is easy. See getting started to make your first deployment.

Instances

Each deployment of an application to the dev zone is a separate instance of the application. Using multiple instances lets developers work with the same application separately or collaboratively as they prefer.

Consider the deploy command:

$ mvn clean package vespa:deploy -DapiKeyFile=/path-to/uname.tname.pem \
  -Denvironment=dev \
  -Dregion=aws-us-east-1c \
  -Dtenant=mytenant \
  -Dapplication=vespacloud-docsearch \
  -Dinstance=myuser

This is equivalent to the vespa:deploy used in the getting started page:

• environment and region defaults to the dev zone.

• tenant and application is normally set in pom.xml.

• instance must be set and can be anything, e.g a user, experiment or team name.

Auto downsizing

Deployments to dev are downscaled to one small node by default so that prod applications can be deployed without changing services.xml. If you need more resources in the dev application, set nodes or resources explicitly by adding those tags to services.xml with a deploy:environment="dev", see variants in services.xml.

Availability

The dev zone is not for production serving, and has no uptime guarantees.

An automated Vespa software upgrade can be triggered by vespa:deploy and that may lead to some downtime if you have only one node per cluster (as with the default auto downsizing).

To override the version, use

-Dvespa.runtime.version=<current deployed version>

when deploying.

Performance testing

In addition to dev there is also a perf zone for performance testing. This does less downscaling of resources, such that tests that can be extrapolated to production are possible. In other ways this zone works the same way as dev. To deploy to perf, use

-Denvironment=perf

Read more in benchmarking.

Tips and troubleshooting

• As Vespa Cloud upgrades daily, a deploy will some times pull the latest Vespa Version. This takes minutes as opposed to the seconds it normally takes. Start the day by deploying to avoid the wait!

• A common mistake is pom.xml mismatch. tenant and application is normally pulled from the pom - details. Errors here cause a 401 when deploying.

• Likewise for data plane - remember to copy the public sertificate to src/main/application/security/clients.pem before building and deploying.

• Set all keys in the IDE:

  -Dtest.categories=system
  -DapiKeyFile=/path-to/uname.tname.pem
  -DdataPlaneCertificateFile=/path-to/data-plane-public-cert.pem
  -DdataPlaneKeyFile=/path-to/data-plane-private-key.pem