diff options
author | Narayan Desai <desai@mcs.anl.gov> | 2005-10-18 23:00:21 +0000 |
---|---|---|
committer | Narayan Desai <desai@mcs.anl.gov> | 2005-10-18 23:00:21 +0000 |
commit | bbe2884f29d448655751c3b995b05bd3b3e47651 (patch) | |
tree | 3b4d5236e134431e27f76d4099e8edcd784b20dc /doc | |
parent | bb44f1573a9088fecbaccec8523bf641129b3970 (diff) | |
download | bcfg2-bbe2884f29d448655751c3b995b05bd3b3e47651.tar.gz bcfg2-bbe2884f29d448655751c3b995b05bd3b3e47651.tar.bz2 bcfg2-bbe2884f29d448655751c3b995b05bd3b3e47651.zip |
Delete: doc/why-is-this-different-from-LDAP
}(Logical change 1.340)
git-svn-id: https://svn.mcs.anl.gov/repos/bcfg/trunk/bcfg2@1402 ce84e21b-d406-0410-9b95-82705330c041
Diffstat (limited to 'doc')
-rw-r--r-- | doc/why-is-this-different-from-LDAP | 30 |
1 files changed, 0 insertions, 30 deletions
diff --git a/doc/why-is-this-different-from-LDAP b/doc/why-is-this-different-from-LDAP deleted file mode 100644 index f670ebe21..000000000 --- a/doc/why-is-this-different-from-LDAP +++ /dev/null @@ -1,30 +0,0 @@ -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. |