remove stale documentation

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

1 files changed, 0 insertions, 117 deletions

diff --git a/doc/deployment.xml b/doc/deployment.xml
deleted file mode 100644
index 4c4cc9bf6..000000000
--- a/doc/deployment.xml
+++ /dev/null
@@ -1,117 +0,0 @@
-<chapter>
-  <title>Deploying Bcfg2</title>
-  
-  <para>
-    Bcfg2 can be deployed in several different ways. The strategy
-    chosen varies based on the level of complexity accepted by the
-    administrators. The more literal a representation used, the less
-    powerful and reusable it is. We will describe three strategies for
-    Bcfg2 deployment, ranging from a cfengine-like deployment, to a
-    highly abstract configuration. While the abstract configuration is
-    much more powerful, the cfengine-like deployment is much easier to
-    understand and manipulate.
-  </para>
-  
-  <section>
-    <title>Simple Deployments</title>
-
-    <para>
-      The Bcfg2 server will build configurations based on a set of
-      high-level specifications that use class-based abstractions to
-      provide reusability. This approach works pretty well; however,
-      it can be hard to deploy and may be too complicated to solve
-      simple problems. 
-    </para>
-
-    <para>
-      This issue can be addressed through the use of the Bcfg2 client
-      with a static configuration specification. This method works as
-      follows: important configuration details are statically
-      specified in a file on each system. The Bcfg2 client runs
-      periodically, and ensures that all aspects of configuration
-      included in the static specification are correct. It then
-      performs any update operations needed on the client.
-    </para>
-
-    <para>
-      The format of static specifications is identical to that
-      provided by the Bcfg2 server, when it is used. It consists of a
-      series of "Bundle" and "Independent" clauses. Independent
-      clauses contain a series of configuration elements that can be
-      installed without any install time dependence on other
-      configuration elements. Bundles are series of dependent
-      clauses. This means that configuration elements may interfere
-      with one another, or that services may need to be restarted upon
-      configuration update. 
-    </para>
-
-    <para>
-      Each of these containers consists of a series of configuration
-      elements. The same elements may appear in either type of
-      clauses. These are basic types that are the same across all OS
-      ports.
-    </para>
-
-  </section>
-
-  <section>
-    <title>A Near-Literal Deployment</title>
-    <para>
-      The next easiest method to deploy is one where the configuration
-      specification is as simple and literal as possible. This style
-      of configuration specification can be characterized as near
-      copies of parts of the system. 
-    </para>
-
-    <para>
-      This style of deployment uses the stock generators: Cfg, Pkgmgr,
-      and Svcmgr. These manage configuration files, packages and
-      services, respectively. Copies of configuration files are placed
-      in the Cfg repository, in as generic a location as possible. 
-    </para>
-  </section>
-
-  <section>
-    <title>An Abstract Deployment</title>
-    <para/>
-  </section>
-
-  <section>
-    <title>Bcfg2 Server Administration</title>
-    
-    <para/>
-
-  </section>
-
-  <section>
-    <title>An example application of bcfg2</title>
-    <para>
-      In my computing environment there are quite a diverse set of machines
-      and requirements for their operation. What this meant was that I needed
-      to devise a build system for machines that would allow me to easily
-      customize the software and services on the machine while still being
-      able to easily manage them and keep them secure. What I came up with
-      that solved this problem was that the initial install needed to be the
-      smallest subset of software that all machines had in common and
-      install this with whatever automated install system fit the OS. The
-      goal being that the OS automated installer( ie: kickstart, or
-      systemimager ) would put the initial bits on disk and take care of
-      hardware stuff and then as part of the postinstall process I run bcfg2
-      to insure that the rest of the software and configuration occurs based
-      on the machines metadata. The overall goal was met. I could now build
-      any type of machine that I needed just by using the common buildsystem
-      and let bcfg2 determine what was different machine to machine.  
-    </para>
-
-    <para>
-      My current build process is centered around systemimager and
-      bcfg2. I have done some small enhancements to systemimager so that
-      with one floppy or cdrom any administrator can build any number of
-      machine profiles automatically. This is all done with some of the new
-      features that allow the encoding of the profile and image in the
-      clientside command so that the back end metadata can be asserted from
-      the client, which overrides the defaults specified in the metadata.xml
-      file.  
-    </para>
-  </section>
-</chapter>