[FEATURE REQUEST] Support an XML-driven State renderer #63778
Labels
Feature
new functionality including changes to functionality and code refactors, etc.
needs-triage
Renderers
Is your feature request related to a problem? Please describe.
I know it's the current fad to hate XML. Hear me out - most people who hate XML are simply unaware of just how powerful it can be natively.
How many GitHub issues are triaged that are due to YAML errors due to chomped or inconsistent whitespace, a misunderstanding about the significance of
:
in the middle of some strings, multiline blocks, etc.?Wouldn't it be great if there was a format that didn't care whatsoever about indentation levels or title string content?
Wouldn't it be even better if that format natively had standardized mechanisms for:
file.managed
'scontents
vs.name
, for instance)Describe the solution you'd like
Ladies, gents, and other: the answer is XML. Specifically, something I think my be catchy: "
.slsx
" (Jinja-wrapped XML, which renders to XML defined by a Salt schema).Describe alternatives you've considered
Not going crazy because of a stray spacebar collision here and there and obtuse and inconsistent error messages, not succumbing to the forever struggle between cleanly rendered states and programmatic covering of a wide and robust infra.
(It hasn't been going well. And I'm probably what would be considered a Salt veteran.)
Additional context
Just a quick, small demo; let's look at what, say, a
file.comment
state might look like in SLS (jinja|yaml
):could look like the following in SLSX:
Now, many people at first say "That looks horrible, I can't read that! YAML is so much nicer!"
Ah, but unlike YAML, the state author can format exactly how they like it.
How about something like, say, this?
It evaluates to the exact same as above. Parser don't care; parser don't give a f- (A document/element's schema can define how each element type should handle leading/trailing whitespace in content).
I know this whole thing seems silly, but I'd recommend tossing the idea around. Think about the benefits I mention above. Mull on it a while.
There is, of course, the stdlib
xml
module, but I'd highly recommendlxml
instead. It would make parsing and validating states an absolute breeze, and has tightly integrated XSD (XML Schema Document) and namespace support built right in.Come, imagine a better future for state definitions with me.
Please Note
If this feature request would be considered a substantial change or addition, this should go through a SEP process here https://github.com/saltstack/salt-enhancement-proposals, instead of a feature request.
The text was updated successfully, but these errors were encountered: