Vaquero Tools

Home Docs Repo  
Migrate Preview Validator

Vaquero Migrate

The Vaquero migrate tool is built for moving and renaming stored information about SoTs and Sites. By default, the tool will check for collisions in the destination storage. If it finds any, it will ask for the user to confirm to continue and overwrite any information.

Potential use cases include:

Using vaquero migrate

Migrating files from one local storage to the destination etcd:

vaquero migrate --src <config_with_local>.yaml --dst <config_with_etcd>.yaml

Migrating and renaming an SoT:

vaquero migrate --src <config>.yaml --dst <config>.yaml --src-sot <src_sot_id> --dst-sot <new_id> --del

Options:

Example configs

Below are some configs showing valid configurations to provide to the migrate tool.

sample-file-store.yaml:
SavePath: "/var/vaquero"
minimal-etcd-store.yaml:
Etcd:
  Endpoints:
  - "http://127.0.0.1:2379"
sample-etcd-store.yaml:
Etcd:
  Root: "vaquero1"
  Endpoints:
  - "http://127.0.0.1:2379"

Vaquero Preview

The Vaquero preview tool is built to prview iPXE and unattended boot scripts for specific host machines.

Using vaquero preview

Preview the cloud config for the host with given MAC:

vaquero preview --mac 00:00:00:00:00:01 --sot examples/etcd-cluster

Preview the iPXE for a given MAC:

vaquero preview --mac 00:00:00:00:00:01 --sot examples/etcd-cluster --ipxe

Preview a specific boot stage for the machine with the given MAC:

vaquero preview --mac 00:00:00:00:00:01 --sot examples/etcd-cluster --boot coreos-partition

Vaquero Validator

The Vaquero validator is a built in utility for checking the consistency of your configurations. Its purpose is to preemptively report any inconsistencies (mistyped IDs, missing metadata, etc) in your configuration before you attempt to deploy it.

Using vaquero validate

Validating a local SoT:

vaquero validate --sot <base_directory>

The base directory structure should be consistent with the data model.

Validation Process

The validator first loads the directory tree passed in through a local directory, or through git. It then:

  1. Checks if all links between objects exist. For example, an error would be generated if a host_group is looking for operating_system: coreos-1053.2.0-stable and the data model only has coreos-1053.2.0-alpha.
  2. Checks if all metadata needed to render templates is available.
  3. Checks unattended files are in a valid format
  4. Checks unattended files mentioned are supported by Vaquero
  5. Checks for name duplication amongst a class of data model objects
  6. Checks if inventory has hosts
  7. Checks if the ignition files provided are valid. Uses coreos/fuze
  8. Checks if the cloud-config files provided are valid. Uses coreos/coreos-cloudinit
  9. Checks if the kickstart files provided are valid using a simple internally developed parser. Further validation can be done using the official validator.