Sophie

Sophie

distrib > Fedora > 17 > i386 > media > updates > by-pkgid > b50d8ee6d7871fcc13c0677a9364ed59 > files > 335

bcfg2-doc-1.3.0-1.fc17.noarch.rpm



<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">


<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    
    <title>Design Considerations &mdash; Bcfg2 1.3.0 documentation</title>
    
    <link rel="stylesheet" href="../_static/default.css" type="text/css" />
    <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
    
    <script type="text/javascript">
      var DOCUMENTATION_OPTIONS = {
        URL_ROOT:    '../',
        VERSION:     '1.3.0',
        COLLAPSE_INDEX: false,
        FILE_SUFFIX: '.html',
        HAS_SOURCE:  true
      };
    </script>
    <script type="text/javascript" src="../_static/jquery.js"></script>
    <script type="text/javascript" src="../_static/underscore.js"></script>
    <script type="text/javascript" src="../_static/doctools.js"></script>
    <script type="text/javascript" src="../_static/sidebar.js"></script>
    <link rel="shortcut icon" href="../_static/favicon.ico"/>
    <link rel="top" title="Bcfg2 1.3.0 documentation" href="../index.html" />
    <link rel="up" title="Detailed Bcfg2 Architecture" href="index.html" />
    <link rel="next" title="The Bcfg2 Server" href="../server/index.html" />
    <link rel="prev" title="The Literal Configuration Specification" href="config-spec.html" />
 
<link rel="stylesheet" href="../_static/bcfg2.css" type=""/>

  </head>
  <body>

<div style="text-align: left; padding: 10px 10px 15px 15px">
<a href="../index.html"><img src="../_static/bcfg2_logo.png" border="0" alt="sampledoc"/></a>
</div>

    <div class="related">
      <h3>Navigation</h3>
      <ul>
        <li class="right" style="margin-right: 10px">
          <a href="../genindex.html" title="General Index"
             accesskey="I">index</a></li>
        <li class="right" >
          <a href="../py-modindex.html" title="Python Module Index"
             >modules</a> |</li>
        <li class="right" >
          <a href="../server/index.html" title="The Bcfg2 Server"
             accesskey="N">next</a> |</li>
        <li class="right" >
          <a href="config-spec.html" title="The Literal Configuration Specification"
             accesskey="P">previous</a> |</li>
	<li><a href="../index.html">home</a> |&nbsp;</li>
	<!--<li><a href="../search.html">search</a> |&nbsp;</li>-->
	<li><a href="../help/index.html">help</a> |&nbsp;</li>
	<li><a href="../contents.html">documentation </a> &raquo;</li>

          <li><a href="../contents.html" >Bcfg2 documentation 1.3.0</a> &raquo;</li>
          <li><a href="index.html" accesskey="U">Detailed Bcfg2 Architecture</a> &raquo;</li> 
      </ul>
    </div>
  

    <div class="document">
      <div class="documentwrapper">
        <div class="bodywrapper">
          <div class="body">
            
  <div class="section" id="design-considerations">
<span id="architecture-design"></span><h1>Design Considerations<a class="headerlink" href="#design-considerations" title="Permalink to this headline">¶</a></h1>
<p>This section will discuss several aspects of the design of Bcfg2, and the
particular use cases that motivated them. Initially, this will consist
of a discussion of the system metadata, and the intended usage model
for package indices as well.</p>
<div class="section" id="system-metadata">
<h2>System Metadata<a class="headerlink" href="#system-metadata" title="Permalink to this headline">¶</a></h2>
<p>Bcfg2 system metadata describes the underlying patterns in system
configurations. It describes commonalities and differences between these
specifications in a rigorous way. The groups used by Bcfg2&#8217;s metadata are
responsible for differentiating clients from one another, and building
collections of allocatable configuration.</p>
<p>The Bcfg2 metadata system has been designed with several high-level
goals in mind. Flexibility and precision are paramount concerns; no
configuration should be undescribable using the constructs present in
the Bcfg2 repository. We have found (generally the hard way) that any
assumptions about the inherent simplicity of configuration patterns tend
to be wrong, so obscenely complex configurations must be representable,
even if these requirements seem illogical during the implementation.</p>
<p>In particular, we wanted to streamline several operations that commonly
occurred in our environment.</p>
<ul>
<li><p class="first">Copying one node&#8217;s profile to another node.</p>
<p>In many environments, many nodes are instances of a common configuration
specification. They all have similar roles and software. In our
environment, desktop machines were the best example of this. Other than
strictly per-host configuration like SSH keys, all desktop machines
use a common configuration specification. This trivializes the process
of creating a new desktop machine.</p>
</li>
<li><p class="first">Creating a specialized version of an existing profile.</p>
<p>In environments with highly varied configurations, departmental
infrastructure being a good example, &#8220;another machine like X but with
extra software&#8221; is a common requirement. For this reason, it must be
trivially possible to inherit most of a configuration specification
from  some more generic source, while being able to describe overriding
aspects in a convenient fashion.</p>
</li>
<li><p class="first">Compose several pre-existing configuration aspects to create a new profile.</p>
<p>The ability to compose configuration aspects allows the easy creation
of new profiles based on a series of predefined set of configuration
specification fragments. The end result is more agility in environments
where change is the norm.</p>
<p>In order for a classing system to be comprehensive, it must be usable in
complex ways. The Bcfg2 metadata system has constructs that map cleanly
to first-order logic. This implies that any complex configuration
pattern can be represented (at all) by the metadata, as first-order
logic is provably comprehensive.  (There is a discussion later in the
document describing the metadata system in detail, and showing how it
corresponds to first-order logic)</p>
</li>
</ul>
<p>These use cases motivate several of the design decisions that we
made. There must be a many to one correspondence between clients and
groups. Membership in a given profile group must imbue a client with
all of its configuration properties.</p>
</div>
<div class="section" id="package-management">
<h2>Package Management<a class="headerlink" href="#package-management" title="Permalink to this headline">¶</a></h2>
<p>The interface provided in the Bcfg2 repository for package specification
was designed with automation in mind. The goal was to support an
append only interface to the repository, so that users do not need to
continuously re-write already existing bits of specification.</p>
</div>
</div>


          </div>
        </div>
      </div>
      <div class="sphinxsidebar">
        <div class="sphinxsidebarwrapper">
  <h3><a href="../index.html">Table Of Contents</a></h3>
  <ul>
<li><a class="reference internal" href="#">Design Considerations</a><ul>
<li><a class="reference internal" href="#system-metadata">System Metadata</a></li>
<li><a class="reference internal" href="#package-management">Package Management</a></li>
</ul>
</li>
</ul>

  <h4>Previous topic</h4>
  <p class="topless"><a href="config-spec.html"
                        title="previous chapter">The Literal Configuration Specification</a></p>
  <h4>Next topic</h4>
  <p class="topless"><a href="../server/index.html"
                        title="next chapter">The Bcfg2 Server</a></p>
  <h3>This Page</h3>
  <ul class="this-page-menu">
    <li><a href="../_sources/architecture/design.txt"
           rel="nofollow">Show Source</a></li>
  </ul>
<div id="searchbox" style="display: none">
  <h3>Quick search</h3>
    <form class="search" action="../search.html" method="get">
      <input type="text" name="q" />
      <input type="submit" value="Go" />
      <input type="hidden" name="check_keywords" value="yes" />
      <input type="hidden" name="area" value="default" />
    </form>
    <p class="searchtip" style="font-size: 90%">
    Enter search terms or a module, class or function name.
    </p>
</div>
<script type="text/javascript">$('#searchbox').show(0);</script>
        </div>
      </div>
      <div class="clearer"></div>
    </div>
    <div class="related">
      <h3>Navigation</h3>
      <ul>
        <li class="right" style="margin-right: 10px">
          <a href="../genindex.html" title="General Index"
             >index</a></li>
        <li class="right" >
          <a href="../py-modindex.html" title="Python Module Index"
             >modules</a> |</li>
        <li class="right" >
          <a href="../server/index.html" title="The Bcfg2 Server"
             >next</a> |</li>
        <li class="right" >
          <a href="config-spec.html" title="The Literal Configuration Specification"
             >previous</a> |</li>
	<li><a href="../index.html">home</a> |&nbsp;</li>
	<!--<li><a href="../search.html">search</a> |&nbsp;</li>-->
	<li><a href="../help/index.html">help</a> |&nbsp;</li>
	<li><a href="../contents.html">documentation </a> &raquo;</li>

          <li><a href="../contents.html" >Bcfg2 documentation 1.3.0</a> &raquo;</li>
          <li><a href="index.html" >Detailed Bcfg2 Architecture</a> &raquo;</li> 
      </ul>
    </div>
    <div class="footer">
        &copy; Copyright 2009-2013, Narayan Desai.
      Last updated on Mar 20, 2013.
      Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
    </div>
  </body>
</html>