CFEngine Yaml?

By asperous (Andy Chase)

Reasons why CFEngine would benefit from YAML-based policy files.

1. 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"

"Admittedly, it is some kind of PITA to get to know Cfengine, i at least spent 24 Hours in migrating my puppet setup to Cfengine, but it was worth it!"

"cfengine for example has a learning curve that makes hard to sell in any meaningful way to an ops team. "

"There is a lot to know about CFEngine, which can make it hard for people new to the subject."

", the language was overly complicated and the learning curve much steeper at the beginning: not exactly the features you want for a tool that should prompt people to use it."

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.

2. 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.

3. 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?

4. 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.

4. Less to type

Not much to say here but YAML is just less to type. That's good.

Why Yaml?

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.

So what am I going to do about it?

Nothing. Just sit here and complain. NOT

I'm going to write a yaml to cf converter and share it with you guys. I'm going to write it in python because I'm lazy and hopefully someone can convert it to C.

I think that eventually cf-promises could have it built in and just let it read .yaml as well as .cf.

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 .cf and .yaml files should co-exists. I think that cf-promises should have a -yaml2cf flag to convert. I'm all for backwards compatibility.

What would it look like?

# Comments still work in yaml - anyway parts in comments show
#   what the yaml would be converted to - or equvialent in .CF
# body command control {               <- Name change for simplicity
main: 
    # bundlesequence => { "test" };    <- Name change for simplicity
    bundles: 
        - test
    
    # inputs => { "cfengine_stdlib.cf" };
    inputs:
        - cfengine_stdlib.cf
# }

# bundle agent test { <- body & bundle autodetected based on if vars, files, reports etc. are in it
#                          oh, and if type is ommitted, it is assumed to be common
test:
    vars:
        # "s1" string => one;   <- Vars is a special case. This makes variables stand out. Type autodetected.
        $s1 = one
    files:
        /tmp/testfile:
            # comment => "this is for keeps"
            comment: this is for keeps
            create: true
            # Semicolon represents function
            # perms => m("612");
            perms: m("612");
    reports:
        # any:: <- case conditions syntax still works in yaml
        any::
            # "s1 = $(s1)"; # <- A lot of parts are really simaliar, like I said
            "s1 = $(s1)"
# }