Forum: CFEngine Help Subject: Thoughts about some cfengine design decisions? Author: lauwersw Link to topic: https://cfengine.com/forum/read.php?3,24285,24285#msg-24285
I'm working for about a year with cfengine community now and I have implemented some pretty complex stuff in it. While I do like it a lot for many reasons, sometimes I had to search hard to get trivial stuff working. Judging from many posts to the forum, I'm not the only one getting bitten occasionally by design decisions or (sometimes rather arbitrary) limitations of cfengine. With this post I want to list some of them and hopefully get some constructive comments. Maybe there are good reasons for some of them, and if not maybe they can even get resolved :-) Let's start with a really common complaint: 1) reports: any:: This is not allowed, if you didn't know it yet. Still what everybody does now is this: reports: cfengine:: Since class "cfengine" is always defined, it has exactly the same effect as the first variant, but people will spend a lot of time finding out why the first, obvious variant doesn't work. I know, it's documented, but the documentation is huge and you can easily miss this. My opinion? If people get an overflow of reports, they will definitely protect the report with a different class. You do test your code first, no? And as cfengine usually has to run as root, people should be aware they have the power to bring the system in deep trouble anyway, they should be used to that. 2) edit_line on arbitrary files is not possible, you can't use it together with file_select for example. Only some wildcards in the path or filename are allowed. I did read the comments in bug 190 about it being a too big hammer, but I don't agree with that. I encountered tasks where I do need to edit a lot of files, so I just resort to shell scripts in that case. I can get bitten with that shell script too. I prefer to be able to do it with cfengine, as it has some nice protections. Also now I have to maintain two separate pieces of code, one in cfengine to setup the script and then the shell script itself. The same closing remarks as above apply: I have a root account anyway, I know I have to be careful. 3) Why is there a difference between global and local classes? In many cases I would prefer to have my local classes to be global. On the other hand I didn't see a case yet where I wanted a global class to be local. If you're afraid of name collisions, you could always apply the "ifvarclass" trick and put a variable in the class name. Now it's just confusing that ifvarclass does generate global classes inside a "local" bundle, while regular class defintions don't. 4) While talking about ifvarclass: this function is very useful, but it also feels a bit unnatural and makes the code hard to read, as you have to look at two places for class restrictions. It would be much nicer if you could just put it all in front, like this: commands: restart_$(service):: I realize it might violate the syntax rules because there are no quotes around the class, but it would feel so much more natural... That's it for now. I must admit that for 1, 3 and 4 once you know the issues, you can easily deal with the problems, but I have the feeling they make the learning curve much harder, while contributing very little. Am I being unreasonable here? Or am I missing out on many other issues? ;-) _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
