<!-- ...................................................................... -->
<!-- $Id: appendix.sgml,v 1.10 2009/01/19 07:36:20 subrata_modak Exp $ .................................................... -->
<!-- 
        This material may be distributed only subject to the terms and 
        conditions set forth in the Open Publication License, v1.0 or later 
        (the latest version is currently available at 
        http://www.opencontent.org/openpub/).  Distribution of substantively 
        modified version of this document is prohibited without the explicit 
        permission of the copyright holder.

        Other company, product, or service names may be trademarks or service 
        marks of others.
-->

  <appendix>
  <title>Appendix A: Design Description Techniques</title>
  <sect1>
    <title>Usage Scenarios</title>
    <para>
      The scope of the SA-Forum's HPI Specification could be interpreted as 
      dealing with only local resources to a platform (where platforms are traditional 
      rack mounted servers or chassis containing many bladed computer systems on a 
      common management bus), or as a network of computer systems. The following usage 
      scenario represents the view of a an OpenHPI implementation that spans across 
      multiple computer systems. 
    </para>
    <para>
      The following scenario is presented to spawn design discussions for OpenHPI 
      and help flush out some of the more vague portions of the HPI specification 
      (like remoting capabilities.) 
    </para>
    <para>
      For this scenario, a rack of computers is closely coupled together to provide a 
      single service in the same way that a single telecommunication application would 
      span across multiple platforms all configured for that one application. 
    </para>
    <para>
      The rack consists of:  
    </para>
    <itemizedlist mark='opencircle'>
      <listitem>
        <para>shelf manager: platform hosting middle-ware that uses OpenHPI to 
          get a platform view of the entire rack of computers 
        </para>
      </listitem>
      <listitem>
        <para>terminal server: common terminal server to aid advanced trouble shooting 
          of a given node 
        </para>
      </listitem>
      <listitem>
        <para>ATCA Chassis: Bladed server chassis full of single board computers 
          and other FRU's all connected together via a common IPMI management bus 
        </para>
      </listitem>
      <listitem>
        <para>DB Server: Traditional database server as is seen in data centers 
        </para>
      </listitem>
      <listitem>
        <para>UPS: A couple of UPS units providing redundant power
        </para>
      </listitem>
    </itemizedlist>
    <para>
      <mediaobject>
        <imageobject>
          <imagedata fileref="images/physical_view.png">
        </imageobject>
      </mediaobject>
    </para>
    <para>
      As mentioned before, the full rack of computers is tightly coupled together 
      to perform a single service, so from the services view this entire setup is a 
      single platform. Assuming OpenHPI contains the ability to remotely plug physically 
      separate computer systems into a single tree as described in the HPI specification, 
      our scenario is configured to see the following HPI view: 
    </para>
    <para>
      <mediaobject>
        <imageobject>
          <imagedata fileref="images/domain_view.png">
        </imageobject>
      </mediaobject>
    </para>
    <para>
      One possible high level design for enabling such a remotely pluggable capabilities could be done like: 
    </para>
    <para>
      <mediaobject>
        <imageobject>
          <imagedata fileref="images/implementation_view.png">
        </imageobject>
      </mediaobject>
    </para>
    <para>
      In the above diagram, the software components that understands specific hardware 
      management components (like IPMI) would be isolated into "domain servers". In 
      addition to this a remote and local mechanism would be provided for domain servers 
      to be plugged into each other, resulting in the HPI tree needed for the specific solution. 
    </para>
  </sect1>
  </appendix>
