diff options
author | Narayan Desai <desai@mcs.anl.gov> | 2004-03-01 22:19:11 +0000 |
---|---|---|
committer | Narayan Desai <desai@mcs.anl.gov> | 2004-03-01 22:19:11 +0000 |
commit | 81c9ecc82c149e22d58930d8b339ad8d0cc2cd93 (patch) | |
tree | cce38b44910836742113472646d089b4c336db86 /doc/why-is-this-different-from-LDAP | |
parent | 59a5ac07bc2bc8972f727184523be67d0fc3a11f (diff) | |
download | bcfg2-81c9ecc82c149e22d58930d8b339ad8d0cc2cd93.tar.gz bcfg2-81c9ecc82c149e22d58930d8b339ad8d0cc2cd93.tar.bz2 bcfg2-81c9ecc82c149e22d58930d8b339ad8d0cc2cd93.zip |
(Logical change 1.18)
git-svn-id: https://svn.mcs.anl.gov/repos/bcfg/trunk/bcfg2@69 ce84e21b-d406-0410-9b95-82705330c041
Diffstat (limited to 'doc/why-is-this-different-from-LDAP')
-rw-r--r-- | doc/why-is-this-different-from-LDAP | 30 |
1 files changed, 30 insertions, 0 deletions
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. |