(Logical change 1.18)

git-svn-id: https://svn.mcs.anl.gov/repos/bcfg/trunk/bcfg2@69 ce84e21b-d406-0410-9b95-82705330c041

2 files changed, 56 insertions, 0 deletions

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. 
+
+<service name='internal-dns' type='dns' scope='local'>
+  <producer host='antares' port='53' type='udp/ip'
+     bundle='dhcp-server'/>
+  <consumer tag='dhcp-config'/>
+</service>
+
+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.