Rule Packs

Explicit migration logic, not hidden magic.

Rule packs are version-pair aware YAML files that describe what the tool should flag, what it may rewrite safely, what it may scaffold for review, and which Apache guidance or caveats back those decisions.

Back to site Open source doc

What a rule pack contains

  • source and target version ranges
  • matchers for processors, controller services, and root-level flow features
  • finding types such as blocked, manual-change, assisted-rewrite, and auto-fix
  • optional actions like property rename, property copy, scaffolded property creation, or component type replacement
  • references back to official Apache migration notes where possible
apiVersion: flowupgrade.nifi.apache.org/v1alpha1
kind: RulePack
metadata:
  name: nifi-2.7-to-2.8-official
spec:
  sourceVersionRange: ">=2.7.0 <2.8.0"
  targetVersionRange: ">=2.8.0 <2.9.0"

Safety boundary

Rule packs should only declare rewrites when the change is mechanically safe and explainable. The middle tier is assisted-rewrite: the tool can scaffold the target shape in a separate output artifact while still leaving the final review decision visible to a human.

Linting

The CLI validates duplicate IDs, duplicate pack names, bad version ranges, and malformed actions before a pack is used in analysis or rewrite.

It also warns on fragile patterns such as match.propertyExists, because exported NiFi JSON can preserve a property key with a null value. Prefer value-based matchers when you need proof of a real configured value.