nwat...@symcor.com writes: > It's too early for me to tell what the best methods of code style will be > for CF. Experience tells me that as policies grow, are deployed to more > hosts and are managed by multiple people such separation of data and > function are very helpful. If others have different styles that they > think are promising I hope that they will share.
In my grad school days, I did a lot of linear programming work, and one of the interesting tools we used was called AMPL (which has an interesting Unix connection in that Brian Kernighan was one of its creators). A free software imitator called ZIMPL recently emerged... The traditional way of expressing LP problems tends, when problems grow large, to turn into them looking either like a) Huge matrices, or b) Lists of hundreds/thousands of linear equations. The AMPL method was to separate data and model, so that, at least for a large proportion of the linear equations, these equations could be derived from data rather than having to be written out literally. This would allow "scaling" ones thinking about the problems. Here's a link to an example; in the example, the set of data is small enough to fit on a screen, indicating a problem optimizing nutrient use from a set of 5 foods. <http://lpsolve.sourceforge.net/5.5/Zimpl.htm> The nifty bit is that the model is already scalable; it would be trivial to extend the table to have 5000 kinds of food instead of 5. And the separation of model and data means that it's no less comprehensible. I tend to think that the use of classes in CFEngine means that it *mostly* already has a similar sort of scalability. Scaling from 5 servers to 5000 frequently *isn't* difficult, as long as you impose some commonalities of policy. Our cfengine policies for tidying log files had, for a while, gotten pretty messy because we had a variety of individualized per-server, per-user, per-probably-something-else locations where logs would live. As a consequence, there were dozens of rules for recognizing them. Recently, as new software went into place, some new policies got set which allowed the number of rules to fall to just a handful, which "scales nicely." One way that AMPL "scales" (which ZIMPL mightn't; not sure) and which mayn't be readily true for CFEngine is in that it can draw data (to give to the models) from external sources. It'll pull tabular data from files, and likely from DBMSes. The last time I was trying to do notably clever things with CFEngine, I was trying to push in extra classes for it to recognize, and that process was clumsier than I liked. - I didn't want to need to hardcode "--define" options; that forces one to "wrap" cfengine runs in order to get all the needed classes - In reflecting on it, I think I'd like for some of the derived classes to be derived out of data residing in external sources like LDAP/DBMS. I could always write a script to pull the data out, and turn it into part of the "classes:" section, but it might be nice to go to the "horse's mouth." At any rate, I'd have to agree that there's a lot of value in providing ways to separate data from model, as that allows the data to scale to larger sizes without that making the model worse. -- select 'cbbrowne' || '@' || 'ca.afilias.info'; Christopher Browne "Bother," said Pooh, "Eeyore, ready two photon torpedoes and lock phasers on the Heffalump, Piglet, meet me in transporter room three" _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
