-
Notifications
You must be signed in to change notification settings - Fork 188
CFEngine Yaml?
By asperous (Andy Chase)
- Easier to learn
When looking for a configuration managment/provisioning engine the biggest thing I saw about CFEngine was although it was very rooted in solid ideas, the syntax was too much of a road block. A road block, not just for the people who wanted to intregrate it into their systems, but very few sysadmins are alone in their sysadminhood.
Often there are others, lurking around the corners. Others that are not as intellectually advanced. The challange to teach these people .CF synax would be too great.
"Sissys (Sysadmins) already know the rubies, so give them the damn rubies (Chef)" - said no one ever. But perhaps thought by many:
"cfengine3 configuration syntax is more difficult than the other three"
"There is a lot to know about CFEngine, which can make it hard for people new to the subject."
Since this is such a breaking point for many CFEngine Inc. would financially benefit from simplifying the syntax Switching to a YAML syntax would be a great start to that. In my implementation I plan to do a few things that will remove unnecessary details as well.
Life easier when you focus on teaching noobs the DSL of CFEngine and not have to teach them both a syntax & also a DSL. I understood yaml the first time I visited yaml.org. I feel like others may have a simaliar experience.
- Easier to transform
There are libraries for YAML. People can use those libraries to write or look over policies files a lot easier. This is a huge boon.
It could also be a con, since policy files should be well thought over and designed, not automashed together by a machine. I think the pros outweigh the cons here. If you give people too much rope to hang themselves, a few might die, but the rest will build a bridge.
- Easier for EYEs
Face the facts: reading yaml is easier. You get rid all the crud you don't need, and you allow yourself to experience a format that reads like a list.
Why is that good? Easier to read policies means more people will read them. More people reading them means that problems are more likely to be seen earlier. This is good.
Write your policies in Japanese and you begin to trust the forieners.
Plus, imagine a world were the policies are so easy to read you can just print them and your boss can read them.-... but that's impossible... right?
- Easier for IDEs
It's just easier when it's a standard format. I couldn't get that eclipse plugin working, and I certainly wouldn't go back to emacs. Writing non-autoindented structured text is painful at best.
Yaml. IDEs love it.
- Less to type
Not much to say here but YAML is just less to type. That's good.
It's my personal favorite. No really, it's the most human readable and easily writable format, I don't think anything else would justify doing this for. CF syntax is sparse compared to something like json or (dare I say its terrible name) xml.
Plus yaml is simaliar to .CF syntax. Just standardized and cleaner. You're still going to have the vars: and the any::, so don't worry about that Mark Burgess.
Also it's declarative. It's not a programming language or based on one. It's just structured data, and that's exactly what CF syntax is. It's really a great fit.
I don't really think CFEngine needs another dependency, so only implement the sub-set of yaml that is actually used in policies and just compile that in.
I AM NOT IN FAVOR OF A SWITCH I think the new formats should co-exists. I'm all for backwards compatibility.
I have taken the freedom to spend many many hours implementing my idea exactly using the community code.
The only changes I made are to the yacc parser file and lex lexing file. My implementation is COMPLETLY backwards compatible. The two can coexist even in the same file.
Remember that the goal is simplicity, ease of learning, as well as yaml-compliance.
- Body Common Control {} is now Main:
This is the most important Body delcaration of the entire file. If people new to the file can't find the starting point of the rest of the system, they can't center themselves and they don't know what's going on.
It is the index that makes the rest fall into place.
I chose main because that's the standard entry point in many language like C.
###############################################################################
#
# promises.cf - Basic Policy for Community
#
# Hash Comments still valud in yaml - anyway parts in comments show
###############################################################################
# body command control { <- Special case, really draws it out.
main:
# Bundles are renamed to promises (or proms) - there may be some library issues with this
promises =:
# Common bundles first for best practice
- "def"
# Agent bundles from here
- "test"
inputs =:
# Global common bundles
- "def.cf"
# Control body for all agents
- "controls/cf_agent.cf"
- "controls/cf_execd.cf"
- "controls/cf_monitord.cf"
- "controls/cf_report.cf"
- "controls/cf_runagent.cf"
- "controls/cf_serverd.cf"
# COPBL/Custom libraries
- "libraries/cfengine_stdlib.cf"
# User services from here
- "services/init_msg.cf"
version =: "Community Promises.cf 3.4.0"
proms agent test():
methods:
any::
"INIT MSG" : {
usebundle =: init_msg,
comment =: "Just a pre-defined policy bundled with the package",
handle =: "main_methods_any_init_msg"
}
"test": {
usebundle =: init_msg,
comment =: "Just a pre-defined policy bundled with the package",
handle =: "main_methods_any_init_msg"
}