Re: [Cfengine-develop] Development plan / meeting

[Andrew Stribblehill]

Quoting Mark Burgess <address@hidden> (2003-02-27 07:17:50 GMT):
> 
> We need some kind of plan for getting started and coming to
> an agreement about goals and timelines with cfengine.
> 
> Some projects are small, some are large, some lead to compatibility,
> others sacrifice compatibility for excellence. I have some definite
> goals for the future, and I am open to suggestions. 
> 
> I would like to avoid too much email - I get enough already, and part
> of the reason for delegating and enlisting help is to get away from
> the computer. We have options:
> 
>  - a workshop to kickstart development (where? when?)
>  - a purely e-mail discussion that converges quickly (like a
>    good cfengine policy) to a concise plan

Exploring the workshop model: it'd be good to know roughly where
developers live. I'm in Durham, in the North of England, and we know
Mark's in Oslo, Norway. If we were able to meet face-to-face, that'd
be great.

However, if we can't do that, email is a good alternative for me.

> My broad goals with compatibility:
> 
>  * objects with scope (self-contained cfengine sub-routines)
>     - cfengine 2.1.0, main problem is how to express this possiblity in the
>       cfengine language, preserving convergence, even with recursion
>     
>  * a model for peer 2 peer policy exchange
>     - cfengine 2.2.0, requires research and simulation

I'd like to extend cfenvd in some manner, to allow it to hear state
information from other related hosts, and give a more configurable
set of things it watches out for. For example, disk usage on more
than just the root partition, user-defined port watching.

Can convergence testing be tightened somehow? Is a Cfengine script
which merely appends a line to a file allowable, or should all
editfiles sections be idempotent? Must we do our convergence tests at
parse-time or can they be delayed till run-time?

editfiles:
  { /tmp/foo
  BeginGroupIfDefined "any"
    Append "Belgium!"
  EndGroup
  }

A simple test for idempotency is: let the edits be defined as a
transformation T and the file, F. If T(F) == F, the script is
certainly idempotent and no edits have occurred. If T(F) != F, find
T(T(F)) and see if it's the same as T(F). If so, the transformation
has caused F to converge to a new stable state. However, this
requires that the convergence test happen at run-time.

Cfservd could do with some file attributes -- currently if we are
allowing access to $(cfrunCommand), it's both read and execute.

> Goals abandoning compatibilty
> 
>  * Redesign/simplification of language and parser

Elimination of at least 50% of the command-line options for cfagent
would please me. If something can be controlled using control
variables, there has to be a jolly good reason to make it
command-line controllable too, in my opinion.

> Anything else is open to discussion.

In the past few weeks, when users have said, "Can I do this", I've
replied, "No but here's a patch to let you do it." I'm not sure this
is the best way to manage the inclusion of features. How do we want
to do it without formalising the process too much?

-- 
FISHER GERMAN BIGHT
SOUTHEAST 5 OR 6, OCCASIONALLY 7, PERHAPS GALE 8 IN FISHER LATER.
RAIN LATER. MODERATE OR POOR