validation-overrides.xml

validation-overrides.xml can be added to the root of an application package (i.e. next to services.xml) to allow a deployment that otherwise fails to validate to proceed. Validations which can be overridden in this way are returned with a dash-separated validation id preceding the validation message, e.g if the message is field-type-change: Changing the type of field 'foo' to 'bar' is not supported the validation id is field-type-change. See ValidationId.java for a list of available validation overrides.

Validations protect against inadvertently corrupting a production instance. Overriding them may be useful e.g if the application is not in production yet or if you think the consequences of inconsistencies or loss of the data in a particular field are fine.

Structure of validation-overrides.xml

<validation-overrides>
    <allow until="iso-8601-date" [comment="any text"]>validation-id</allow>*
</validation-overrides>
Any number of allow tags is permissible.

<allow>

An allow-tag disables a particular validation for a limited time.

Attributes of <allow>

Attribute nameValueMandatory
until The last day this change is allowed, as a ISO-8601-format date in UTC, e.g 2016-01-30. Dates may at most be 30 days in the future, but should be as close to now as possible for safety, while allowing time for review and propagation to all deployed zones. Allow tags with dates in the past are ignored. Yes
comment Any text explaining the reason for the change to humans. No

Content of <allow>

A single validation id. Allow tags with unknown ids are ignored.

Example

<validation-overrides>
    <allow until="2016-01-31" comment="Reduce to needed cluster size after benchmarking by Trygve">cluster-size-reduction</allow>
    <allow until="2016-02-03">field-type-change</allow>
    <allow until="2016-02-20" comment="Vespa 5.119 disallows our application, but it works on 120.">skip-old-config-models</allow>
</validation-overrides>