Configuration as Code: Bulk Operations and JSON Output in qconf

If you've ever configured a Gridware cluster, you know the ritual. You run qconf -mq, an editor pops open, you change one line, you save, you quit. Then you do it again for the next queue. And the next. Now do it forty times — and then do it again next month because something drifted, and try to remember what "something" was. It's cooking every meal from scratch, by heart, with no recipe written down. Fine for one dish. A nightmare for a banquet.

The interactive editor is a fine paring knife and a terrible production kitchen. Cluster configuration is banquet work: dozens of objects you want to back up, diff, review, and re-apply as a set. There was no clean way to snapshot the whole thing, no history, no "what changed last Tuesday," and no way to hand a config to a script without teaching that script to drive an editor.

The next non-patch release fixes this. qconf gains a complete file- and directory-based interface for every configuration object, plus structured JSON. Put together, the headline is simple: you can finally write your recipes down — and treat your cluster configuration like code.

Bulk add, modify, and delete: cook the whole menu at once

The file-based operations you already know — -A<obj> to add, -M<obj> to modify, -D<obj> to delete — now accept a whole directory as well as a single file. A directory is your recipe box; qconf reads every card in it in one go:

qconf -Mconf hosts/      # apply every host config file in hosts/, in one batch

A directory is processed as one batch. Every object in it is applied in a single request, and you get a one-line summary at the end: how many processed, how many failed. No more shell loops that bail halfway and leave you guessing about state. There's also a name-list delete for the times you know exactly which cards to pull from the box:

qconf -dq old_q1,old_q2,old_q3      # three queues, one call

This works across the board — calendars, complex entries, checkpointing environments, host and global configs, execution hosts, host groups, parallel environments, projects, cluster queues, resource quota sets, usersets and users, plus the share tree and scheduler config.

Add and modify finally stopped arguing

Here's the quietly important part. -A and -M no longer care whether the object already exists. Applying a file creates the object if it's missing and modifies it if it's there. Re-applying the same file is a no-op the second time, not a fistfight.

It's the difference between cooking from a recipe and cooking from memory: a written recipe makes the same dish every single time. Idempotency sounds like a word invented to make standups longer, but it's the whole ballgame here. Add creates or updates, modify updates or creates, and deleting something that's already gone gets reported and skipped rather than blowing up your script. That convergence — describe the desired state, apply it, get the same result every time — is exactly the property every configuration-management tool relies on. Now qconf has it natively.

Closing the loop: export with -S<obj>

None of the above is much use for backup or version control without a way to get the recipes out of your head and onto cards. That's the new save operation, -S<obj> — the inverse of the file-based add:

qconf -Sq queues/        # dump every queue to queues/, one file each, named after the queue
git add queues/ && git commit -m "baseline cluster config"
qconf -Aq queues/        # re-apply later, intact

Export writes one re-importable file per object, named after the object. You can grab a single card by name too (qconf -Sprj myproject). And here's a detail worth getting right: the exported files use exactly the format the importer reads, so they round-trip back through -A/-M unchanged.

That's a deliberate design choice, not an accident. A good recipe card lists the ingredients — not the steam rising off the pan while you cook. The export captures your configuration intent, not transient runtime noise. An execution host, for instance, is written without its live load_values, because those are reported by the host at runtime, not something you configure, and a re-import shouldn't choke on them. So the rule of thumb: exported files are re-importable, which is what you actually want for backup and version control. They're not meant to be a byte-for-byte transcript of what -s<obj> prints on screen.

Safety rails (for when it's 2 a.m.)

Bulk power without a preview is how you delete a cluster. So the batch operations come with guard rails — read the recipe before you light the stove:

• -dry previews exactly what a directory-based add or delete would do, without ever contacting the qmaster. Measure twice.
• -strict validates the whole directory first and applies nothing if any single file is malformed — all-or-nothing, when you want it.
• -f is required to overwrite an existing export file, and to skip the confirmation prompt on a directory-wide delete. The safety is on by default; you opt out explicitly.

qconf -dry -Dq queues/      # show me what you WOULD delete. don't actually.

And if an object's name isn't a valid filename — or two names would collide on a case-insensitive filesystem — export refuses and tells you, rather than silently mangling the name and quietly losing a card.

Structured JSON with -fmt json: measurements, not "a knob of butter"

For years, parsing qconf output meant awk incantations handed down like family recipes — and family recipes are famously vague. The new -fmt json option swaps "a knob of butter" for real measurements. It works on show (-s<obj>), the file-based add/modify (-A/-M), and export (-S):

qconf -fmt json -Sp pes/ | jq '.slots'      # real types, no string-parsing roulette

The values are natively typed: a number is a number, a boolean is a boolean, memory is emitted as bytes instead of "16G" that you have to teach a script to multiply, and nested things are nested arrays. It's validated against published JSON schemas, so it's safe to feed straight into jq, your own scripts, or a configuration-management framework. The classic ASCII format remains the default — JSON is strictly opt-in, so nothing you have today breaks.

Putting it together: the shared cookbook

Snap the pieces together and a familiar workflow appears — the one you already use for application code, now for your cluster. Your config stops being lore locked in one administrator's head and becomes a shared, versioned cookbook:

# 1. Snapshot the whole config into a repo
qconf -Sq queues/
qconf -Sp pes/
qconf -Sconf hosts/

# 2. Commit it — now you have history and blame
git add . && git commit -m "cluster config baseline"

# 3. Someone proposes a change → review the diff in a pull request

# 4. CI applies it, strictly and idempotently
qconf -strict -Aq queues/

Export, diff, review, version-control, re-apply. Because the apply is idempotent and -strict is all-or-nothing, a CI job can run it on every merge without fear of half-cooked state. This is the foundation for managing a Gridware cluster with the same standard configuration-management workflows you use everywhere else.

Availability

These changes land in the next non-patch release, in both Open Cluster Scheduler and Gridware Cluster Scheduler. They're additive — every new option sits alongside the existing ones, and nothing about your current commands changes.

Your cluster configuration is now, finally, just… files. Recipes you can read, share, and trust to come out the same every time. Boring. Wonderful.