CFEngine Yaml?

By asperous (Andy Chase) Pull request here.

    ###############################################################################
    #
    #   promises.cf - Basic Policy for Community
    #
    # Hash Comments still valid in yaml
    ###############################################################################

    # body command control {     <- Special case, really draws it out.
    main:
        bundles =: # <- Synonym for bundlesequence
              - "def"
              - "test"
    
        inputs =:
            # Backwards compatible, tested in all these files:
              - "def.cf"
              - "controls/cf_agent.cf"
              - "controls/cf_execd.cf"
              - "controls/cf_monitord.cf"
              - "controls/cf_report.cf"
              - "controls/cf_runagent.cf"
              - "controls/cf_serverd.cf"
              - "libraries/cfengine_stdlib.cf"
              - "services/init_msg.cf"
    
        version =: "Community Promises.cf 3.4.0"
    
    bundle agent test():
        methods:
            any::
                ^"INIT MSG": # <- Promisers need to wear a hat ^
                    -- usebundle =: init_msg # <- Double dash for promise
                    -- 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"

        reports:
            cfengine_3::
               ^"Hello world!" :

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?

Yaml is similar to .CF syntax. Just standardized and cleaner. Don't worry Mark Burgess, you're still going to have the vars: and the any::.

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.

So what am I going to do about it?

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.

What changes have I made specifically?

Remember that the goal is simplicity, ease of learning, as well as yaml-compliance.

1. Body Common Control {} is now Main:

This is the most important Body declaration 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. Other alternatives I considered was index & *. Star wasn't YAML compliant, and I figured sysadmins were more familiar to C than html.

2. Body is now attr

First off I wanted a much bigger name difference between the two. They should be completely different.

Since bodies are just promise attribute declarations I thought it would make sense to call them attr.

'Bundles' is the strangest term for "A collection of Promises". It's the wrong term, we should focus on what they are, the structure allows you to store promises. Anyway proms is short for promises if you didn't catch that already.

3. => is now =:

This is for two reason. One for YAML compliancy. Two because it makes var assignment look more like an assignment. I couldn't make it just : because of how YACC works. It would be too ambigious.

Now is a good time to make an important note. I did not tokenize newlines or whitespace at all. Even though YAML looks at whitespace; I tried, believe me, but it was just too complicated to have YACC handle that kind of input.

4. Lists can be made in YAML format

Pretty amazing if you ask me, but take a look at the code example above.

5. Body & Bundle declarations now need parameters braces and a colon

The reason why I want to include parameters is to show that they can be added. The colon is for YAML.

NOTE: main: doesn't use parameter braces. Who would pass parameters to it?

6. Body & Bundle declarations don't need curly braces

For YAML conformance and for less typing.

7. Promisers need to wear a hat (they need to start with a circumflex), & Promises need to start with a double dash --.

This makes it a lot more readable, hopefully less ambiguous for the parser, and makes it a little easier to point out the promisers. They're all wearing hats!

And that's it! 7 changes that make CFEngine simpler, more secure, YAML-compliant, and easier for newbies.