On 2/10/2010 2:00 AM, Mark Burgess wrote:
>> Can a mostly-uncoordinated
>> set of people write different parts of a cfengine conf without namespace
>> collisions? Is there a way to track internal version dependencies among
>> the parts?
>
> Yes, there are private name spaces in cfengine. Cfengine Nova tracks
> dependencies between
> the parts. Versioning can be dealt with in a number of ways. There's no
> silver bullet
> there, but a dozen possibilties. I recommend that you don't have thousands
> of people involved however ;-) At some point you can only coordinate multiple
> inputs by
> having a *human* review the final aggregate policy, because a *human* must
> take
> responsibility for it. Many cooks, etc.
There will be a very large cost in having the developers who understand
the requirements of the applications learn another language to control
it - and not a clear win over spending the time making the apps more
self-sufficient in their native languages. I could possibly be
convinced on that point and even the extra QA effort to understand and
test the corner cases before releasing to production. The part I don't
see as a good fit is how the operations scheduling team that manages the
physical machines and is ultimately responsible for keeping things
working would interact with it - they aren't programmers. They need to
control how many instances of what version of what apps are running and
shouldn't have to know much more than the name and version of the app to
do it. They can punt the grunge work back to someone else, but if they
do, the tool won't have helped us. And if they have to punt to an
expert in cfengine details, it's a net loss.
> You should look at the Special Topics Guide on Teamwork. And Knowledge
> Management (e.g.
> Cfengine Nova) is going to be your friend. See that Special Topics Guide too.
I think I saw that, with a pretty picture of interconnections but no
details about the mechanisms involved to separate the roles. Examples
would be very helpful, particularly where external tools like the
version control system come into play.
>> Yes, I'm intrigued at some of the concepts here, but some things aren't
>> assumptions, they are just facts. And I want the program to work for
>> the humans, not the other way around.
>>
>
> This is a good goal indeed.
Part of what is making this difficult for me is that I have some
fundamental philosophical differences with what you describe as the
purpose of the tool and it is hard to separate what freedom you have in
the language to control the policy and what it forces on you. That's
probably just my misconception from the beginning descriptions but short
of spending months learning the language those documents are all I have
to go on. For example, I consider quietly fixing a problem as
inherently evil, and automating such a fix instead of permanently
replacing the underlying component with something that works correctly
is even worse. Never mind all the times we have to make this compromise,
it means the application will never be fixed. Also, in our environment
of many network-connected components it is rare for a machine to be able
to diagnose it's own problems let alone know a useful solution.
Generally we just want to disable any problematic components (or even
whole sites) and let redundancy handle the load until we put things back
the way they were yesterday (even if the app developer didn't anticipate
going backwards). I don't think it would be wise to distribute the
decision of when/what to disable since it requires some comparative
knowledge about the state of all the other machines. The details there
aren't important compared to the question of whether the language that
you imply has to be specialized for this job actually imposes
constraints on the policies it can implement - or makes some difficult
to express.
--
Les Mikesell
lesmikes...@gmail.com
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
