On 08/23/2011 07:32 AM, David Lee wrote: > cfengine distributes an "update.cf". That ought to be high quality and > reliable. But what I find is that this DISTRIBUTED version seems not to > have been written with flexibility in mind. In other words, the example > code from cfengine, about its own product, is suboptimal and sets a > somewhat deficient example of its very own intention. > > I, the end-user, ought to be find the provided "update.cf" to be a good, > well-worked, and flexible example. And I ought to be able to take it > and, with the absolute minimum of changes, incorporate it into my local > environment. Note that "absolute minimum of changes".
This is something which several people including myself have pointed out. I think that the reason is because the creators view cfengine as a framework not a "plug n play" application. How do you "update"? Well that depends on your infrastructure. Some people pull everything from version control to every client. At some scale that might be a bottleneck. Some people use cfengines file serving ability to only copy the inputs necessary for that specific host, some people copy all inputs to every node. That leaves out the other files that you might distribute, how are those delivered? In some organizations it may be a shared nfs mount, others may include it in version control or distribute it through cfengine to all nodes, or only to select nodes. I think there are many more permutations of what you might want to do in an "update". And I think thats why the examples we see strike us as inflexible. Its a valid point, how can you possibly abstract all of those options yet keep the surface area small enough to still understand for a simple use case? I don't think that lets people off the hook. We still need good functional examples. "myexample" or "mycopybody" isn't really something you would ever write in your policy. It's really not descriptive at all. It only tells us its yours. What I think is really needed are example infrastructures with aptly named body parts and bundles that make sense when you read through the policy. You can decide which example infrastructure "fits" you best and build on it, or you can decide that none of them do but learn from the different ways to organize information and policy and build your own. The issue is, thats a big task :). I think its something we will see in the future, but its going to take a while to form. In addition to that a system akin to puppets puppetforge or cpan etc (its been mentioned in the past) would be nice for modular bundles. There is the COPBL but Its mainly for body parts, There is a github account Aleksey started but it has minimal participation so far https://github.com/cfengine/contrib. -- Nick Anderson <n...@cmdln.org> _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
