Importer

jaque import is a compiler, not a migration wizard you babysit through a dozen screens: point it at a config tree, get CUE and an honest report back.

Running it

jaque import -from nagios /etc/nagios/ -o jaque.cue

The positional argument is a directory (jaque looks for nagios.cfg inside it, per Nagios’s own convention) or a single file. -from accepts nagios today. -o writes the CUE to a file; without it, CUE goes to stdout and the report to stderr, deliberately on separate streams so piping to a file never mixes them.

The pipeline

nagios.cfg
  -> include resolution   (cfg_file=, cfg_dir=, resource.cfg for $USERn$)
  -> parse                (define blocks -> AST, every node keeps file:line)
  -> inheritance resolution (use/name/register -> effective objects)
  -> semantic mapping      (effective objects -> jaque's internal IR)
  -> structure recovery    (shared values factored back into CUE templates)
  -> emit                  (CUE AST via cue/ast + cue/format) + report

Nagios’s use chains are ordered multiple inheritance with additive values (+value) and unset (null) — semantics that don’t map 1:1 onto CUE’s unification, so the importer never translates a template directly. It flattens every object using Nagios’s own resolution rules first (the correctness anchor, most heavily golden-tested part of the pipeline), then factors shared values back out into CUE templates for a readable emit — when that recovery is ambiguous, it emits flat rather than guess, and says so in the report.

The migration report

Every source object gets one line: mapped, approximated (translated, but something changed — the report says what), or unsupported (dropped, with file:line). The header carries the trust-anchor number:

objects: N emitted of M in source (P% survived)

That’s the one metric that matters — not “import succeeded,” but how much of the source tree actually made it across. The report is designed to be truthful before it’s flattering: an object silently dropped and called mapped anyway is worse than one honestly marked unsupported.

What’s mapped vs. approximated vs. unsupported

Roughly:

• Mapped, 1:1: hosts, services, most check_command translations, parents, timeperiods reducible to (weekday, range) windows, contacts onto jaque’s four contact types, hostgroup-based services (kept as a group-level definition, never exploded into per-host copies).
• Approximated: notification_options combinations that don’t map cleanly onto jaque’s notification kinds — the report names what changed.
• Not supported today: event handlers, obsess_over_*, most escalation directives, and — deliberately — any object mixing active and passive checks. jaque’s schema models a check as one type; an object trying to be both active and passive at once has nowhere well-defined to go, so it’s reported rather than guessed at.

Verified how far, honestly

Round-trip correctness (emit → re-parse via config.NewConfig → compare) is property-tested against generated configs. What’s not yet done: verification against a real-world corpus at the scale that would let this page claim a concrete coverage percentage across “typical” Nagios estates — that’s still pending. Treat the emitted CUE as a strong first draft, always validated with jaque -config jaque.cue before you trust it, and read the unsupported lines before deciding the import is complete.

Icinga 2: not yet

The importer pipeline is built to host more than one frontend, but only Nagios is implemented today. An Icinga 2 frontend is not built.