From 81c9ecc82c149e22d58930d8b339ad8d0cc2cd93 Mon Sep 17 00:00:00 2001 From: Narayan Desai Date: Mon, 1 Mar 2004 22:19:11 +0000 Subject: (Logical change 1.18) git-svn-id: https://svn.mcs.anl.gov/repos/bcfg/trunk/bcfg2@69 ce84e21b-d406-0410-9b95-82705330c041 --- doc/service-model | 26 ++++++++++++++++++++++++++ doc/why-is-this-different-from-LDAP | 30 ++++++++++++++++++++++++++++++ 2 files changed, 56 insertions(+) (limited to 'doc') diff --git a/doc/service-model b/doc/service-model index e69de29bb..26d628cb3 100644 --- a/doc/service-model +++ b/doc/service-model @@ -0,0 +1,26 @@ +One of the more grungy and fragile portions of the bcfg1 configuration +description interface is that of bundle allocation. To wit, tags are +used for two purposes in this same process. The first use is for +initial choice of the software complement for any particular node. The +second use is for specialization of particular nodes. The use of a tag +for either purpose isn't particularly discernible from the other, +moreover, tags can be used for multiple purposes simultaneously. + + + + + + +There is a whole lot going on here, so i will highlight the +particulars i think are important. +1. There is explicit linkage between a service and the software that + provides it. +2. there is an explicit scope to describe "how far" the service goes +3. there is a notion of what network transport is required. +4. you can construct monitoring/firewalling rules from this +5. you can infer failure cascades from the relationship +6. tags are used in choosing configurations as a specialization + mechanism, no just through bundles. + +How do we extend the idea of coherence from bcfg1? \ No newline at end of file diff --git a/doc/why-is-this-different-from-LDAP b/doc/why-is-this-different-from-LDAP index e69de29bb..f670ebe21 100644 --- a/doc/why-is-this-different-from-LDAP +++ b/doc/why-is-this-different-from-LDAP @@ -0,0 +1,30 @@ +1. what we aren't + +I feel the need to write this to describe why our approach isn't the +same as the LDAP approach. When designing any metadata-based +configuration management system, there is substantial temptation to +start describing all aspects of the system that are relevant to system +configuration. This approach leads to a few things. First, there are +many long discussions that center around the proper representation +for particular constructs. (ie, what attributes does a network +interface have) The second outcome is that configuration details that +might get used are typically included. This stems from the desire to +have a comprehensive solution. The third, and most useful outcome is a +large knowledge base from which many details of system configuration +can be queried. This, in general, is a noble goal, but tends to +require a lot of pain to get there. + +Switching to a BCFG1 install involved a good amount of pain/effort in +order to classify software components into categories dictated by our +model. I am not sure how well a more complicated process would be +accepted by any user community. + +2. how to do better + +Any system will have complex portions of configuration, and +site-specific oddities. A single, simple description scheme certainly +won't provide the flexibility required to model complex +interdependencies. The approach we are taking is to provide a simple +scheme while allow arbitrary logic to be embedded. (generators) Using +this scheme, simple configurations remain simple, and complex +configurations are possible. -- cgit v1.2.3-1-g7c22