[Infrastructures] Infrastructures.Org rework
Steve Traugott
stevegt@TerraLuna.Org
Wed, 22 Feb 2006 12:43:07 -0800
Hi Kevin, Joel, All,
Kevin, a few years ago you posted the Infrastructure Design Patterns
idea below. Developments at a current client tell me that, maybe now
more than ever we (1) need a pattern library, and (2) now have enough
material to populate it. The case I'm encountering right now is one
in which lack of generally available and concise patterns, a library
to refer to, is causing a great deal of semantic difficulty. There is
still not a general understanding, even among senior UNIX folks who
should know better, that use of a given pattern in an infrastructure
implies certain behaviors, costs, and compatibility (or not) with
other patterns. I'm watching yet another case of an organization
spending a great deal of time and money, and enjoying some pretty
painful internal conflict, while trying to re-invent things that at
least half the members of this list already learned the hard way.
Joel, you and I have spoken 1:1 several times about the idea of moving
the current contents of infrastructures.org into a wiki, so that it
can be expanded on and updated, getting us out of being the editorial
bottleneck, and so on. We have the beginnings of a good pattern and
standards library, but it is showing its age. You and I seem to have
agreed that we can do this move without messing up our copyright and
preventing us from publishing print versions; there is probably
precedent in blogs, other wikis, creative commons licenses, etc. I
think we decided we can do this, but just in case, I'm asking again,
formally and in public, so that we know our i's are dotted: Joel, can
I rework infrastructures.org into a community-edited site, provided
that you and I reserve the right to publish the resulting text without
having to go back and later get individual authorization from each
contributor?
Everyone else; the question I have for you is this: Would you be
willing to contribute to a wiki or other community-edited repository
of documents which serve as design patterns and RFC-like standards
documents, in which, by contributing, you might be listed in a
"contributors" section, but would not retain copyright in your
contribution? I hate doing it that way, but it's the only way we'd be
able to easily print the result. I'm not doing this for profit motive
-- bog knows very few technical book authors make significant income
from the proceeds, and this is such a niche that we may never be able
to get it published except via e.g. lulu.com. The only reason for
publishing on paper at all is to try to get wider dissemination and
make all of our jobs easier.
An example to emulate, for instance, might be the Python Cookbook;
recipes drawn from the web site are published in an O'Reilly book, and
the primary contributors are credited with each recipe. A portion of
proceeds can be fed back into the community in some way, etc. There
are probably several ways of doing this, and I'm sure there are people
out there who would already have in mind how this should be licensed;
please feel free to provide suggestions.
We've all talked sporadically over the years about variations of this,
have wished for RFC-like documents, and have even discussed document
file formats. I think we're finally now at the point where I have the
incentive, the time, and the tools to actually do something about it,
and I think we need to take advantage of the opportunity while it's here.
Take Care (and let me know what you think),
Steve
On Fri, Oct 11, 2002 at 01:16:24PM -0400, Kevin M. Counts wrote:
>
> I thought it might be fun to come up with some
> Infrastructure Design Patterns and I have taken
> a stab at one entitled "BootHook".
>
> For anyone not familiar with design patterns,
> a good start might be:
>
> http://www.enteract.com/~bradapp/docs/patterns-intro.html
>
> In a nutshell, they are a named solution to a recurring
> problem in a particular context. They don't say exactly
> how to do something but instead provide a general
> architectural discussion of one or more solutions to
> the problem.
>
> By developing a set of patterns for a domain
> a "Pattern Language" emerges which provides a
> common ground to communicate the architectural
> concepts with others without having to cover
> as many "low-level" implementation details.
>
>
> -- Kevin
>
> .___________________________________.
> | Kevin Counts kcounts@usf.edu |
> | 813.974.1466 (w) 727.460.9522 (c) |
> | http://www.digicat.org |
> `-----------------------------------'
>
>
>
> #-------------------------------------------------------------------------
> # Pattern Name
> #-------------------------------------------------------------------------
>
> BootHook
>
> #-------------------------------------------------------------------------
> # Also Known As
> #-------------------------------------------------------------------------
>
> -nil-
>
> #-------------------------------------------------------------------------
> # Intent
> #-------------------------------------------------------------------------
>
> Deploy software with functionality to update itself via a
> configuration repository and invoke configuration actions on the host's
> local environment.
>
>
> #-------------------------------------------------------------------------
> # Motivation
> #-------------------------------------------------------------------------
>
> Centralized management is a key design in infrastructure implementation.
>
> A popular implementation of this design is establishing a central server
> which is responsible for initiating distribution of software and
> modifications on the infrastructure hosts' local environment.
>
> Although this meets the fundamental requirements, it has several
> consequences:
>
> - Distributions must be synchronized with the availability of the
> infrastructure hosts. Unavailable hosts and missed updates may
> establish a need for complex, fault tolerant logic.
>
> - As the infrastructure scales, performance requirements may require
> a more complex implementation of multi-threaded distribution.
>
> In contrast, the BootHook pattern enables each infrastructure host as
> a self-modifying entity. Host synchronization and multi-threaded
> distribution are handled implicitly through this passive, delegated design.
>
> The configuration repository retains control of the resources and rules
> for the infrastructure but delegates the timing of the actions to the host.
>
>
> #-------------------------------------------------------------------------
> # Applicability
> #-------------------------------------------------------------------------
>
> Use this pattern when:
>
> - You want to configure an infrastructure host with a small initial
> software footprint.
>
> - You want to avoid pushing out changes and allow the infrastructure
> hosts to control their update schedule.
>
>
> #-------------------------------------------------------------------------
> # Structure
> #-------------------------------------------------------------------------
>
> |---------------------------------|
> | Infrastructure Host |
> | |
> | |
> | (3)configuration |
> | actions |(1)request update |---------------|
> | <----------------*|----------|*---------------------->| |
> | | BootHook | | | Configuration |
> | | Software | |(2)updated software | Repository |
> | |----------|<----------------------*| |
> | | |---------------|
> |---------------------------------|
>
>
> #-------------------------------------------------------------------------
> # Participants
> #-------------------------------------------------------------------------
>
> BootHook Software
> A minimal set of software with self-contained functionality to
> contact the Configuration Repository, update itself, and invoke
> configuration actions on the Infrastructure Host.
>
> Configuration Repository (a.k.a. Gold Server)
> The central repository where infrastructure software and configuration
> resources are stored.
>
> Infrastructure Host
> Any host machine managed by the infrastructure configuration management
> system.
>
>
> #-------------------------------------------------------------------------
> # Collaborations
> #-------------------------------------------------------------------------
>
> The BootHook Software will always contact the Configuration Respository
> to obtain the latest copy of its own environment and configuration
> information. It then invokes software housed in its environment which
> performs configuration actions on the Infrastructure host.
>
>
> #-------------------------------------------------------------------------
> # Consequences
> #-------------------------------------------------------------------------
>
> The BootHook pattern has the following benefits and liabilities:
>
> - It gives the host control of when updates occur.
> The passive nature of the pattern makes synchronizing a series of
> updates and reboots a trivial task.
>
> - Because it is a passive update model, updates may not propogate
> in an acceptable time frame.
>
>
>
> #-------------------------------------------------------------------------
> # Implementation
> #-------------------------------------------------------------------------
>
> The BootHook software is often initiated by a start-up script on
> the Infrastructure Host. At boot, the latest copy of the environment
> is updated from the Configuration Repository and actions can be
> performed before the host goes into service.
>
> In addition, a scheduler is usually configured initiate the BootHook
> on a schedule for periodic updates.
>
> One caveat of the BootHook pattern is the passive design may not meet
> certain update time-window requirements. A solution is to employ a
> push model to trigger the passive update when required.
>
>
>
> #-------------------------------------------------------------------------
> # Sample Code
> #-------------------------------------------------------------------------
>
>
> #!/bin/sh
>
> #-- Download the latest copy of this script from the Configuration
> #-- Repository and if it has changed, execute the new version.
>
> ${RSYNC} ${REPOSITORY}/${BOOKHOOK_ROOT}/sbin/boothook.sh /tmp
>
> if cmp -s ${LOCAL_BOOTHOOK_ROOT}/sbin/bookhook.sh /tmp/boothook.sh ; then
> .
> else
> cp /tmp/bookhook.sh ${LOCAL_BOOTHOOK_ROOT}/sbin/boothook.sh
> exec ${LOCAL_BOOTHOOK_ROOT}/sbin/boothook.sh
> fi
>
> #-- At this point we have the latest copy of boothook.sh.
> #-- Now update the entire BookHook environment and run the
> #-- the program to invoke configuration actions on the
> #-- local Infrastructure Host.
>
> ${RSYNC} ${CONFIG_REPOSITORY}/${BOOTHOOK_ROOT}/ ${LOCAL_BOOKHOOK_ROOT}
>
> ${LOCAL_BOOTHOOK_ROOT}/start_config_actions.sh
>
>
>
> #-------------------------------------------------------------------------
> # Known Uses
> #-------------------------------------------------------------------------
>
> The BootHook pattern is used in the ISConf (Infrastructure Configuration
> Engine) framework. (http://www.infrastructures.org)
>
>
> #-------------------------------------------------------------------------
> # Related Patterns
> #-------------------------------------------------------------------------
>
> -nil-
>
>
>
>
> ==========================================================================
> # Below are the descriptions of the sections of a design pattern for
> # reference or if you would like to fill it in and post a new one :-)
> ==========================================================================
>
>
> #-------------------------------------------------------------------------
> # Pattern Name - The pattern's name conveys the essence of the pattern
> # succinctly. A good name is vital, because it will
> # become part of your design vocabulary.
> #-------------------------------------------------------------------------
>
>
> #-------------------------------------------------------------------------
> # Also Known As - Other well-known names for the pattern, if any.
> #-------------------------------------------------------------------------
>
>
>
> #-------------------------------------------------------------------------
> # Intent - A short statement that answers the following questions:
> # What does the design pattern do? What is its rationale and
> # intent? What particular design issue or problem does it address?
> #-------------------------------------------------------------------------
>
>
> #-------------------------------------------------------------------------
> # Motivation - A scenario that illustrates a design problem and how the
> # class and object structures in the pattern solve the
> # problem. The scenario will help you understand the more
> # abstract description of the pattern that follows.
> #-------------------------------------------------------------------------
>
>
> #-------------------------------------------------------------------------
> # Applicability - What are the situations in which the design pattern can
> # be applied? What are examples of poor designs that the
> # pattern can address? How can you recognize these
> # situations?
> #-------------------------------------------------------------------------
>
>
> #-------------------------------------------------------------------------
> # Structure - A graphical representation of the patttern.
> #-------------------------------------------------------------------------
>
>
> #-------------------------------------------------------------------------
> # Participants - The classes and/or objects participating in the design
> # pattern and their responsibilities.
> #-------------------------------------------------------------------------
>
>
> #-------------------------------------------------------------------------
> # Collaborations - How the participants collaborate to carry out their
> # responsibilities.
> #-------------------------------------------------------------------------
>
>
> #-------------------------------------------------------------------------
> # Consequences - How does the pattern support its objectives? What are
> # the trade-offs and results of using the pattern? What
> # aspect of system structure does it let you vary
> # independently?
> #-------------------------------------------------------------------------
>
>
> #-------------------------------------------------------------------------
> # Implementation - What pitfalls, hints, or techniques should you be aware
> # of when implementing the pattern? Are there language-
> # specific issues?
> #-------------------------------------------------------------------------
>
>
>
> #-------------------------------------------------------------------------
> # Sample Code - Code fragments that illustrate how you might implement
> # the pattern.
> #-------------------------------------------------------------------------
>
>
>
> #-------------------------------------------------------------------------
> # Known Uses - Examples of the pattern found in real systems.
> #-------------------------------------------------------------------------
>
>
>
> #-------------------------------------------------------------------------
> # Related Patterns - What design patterns are closely related to this one?
> # What are the important differences? With which other
> # patterns should this one be used?
> #-------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Infrastructures mailing list
> Infrastructures@mailman.terraluna.org
> http://mailman.terraluna.org/mailman/listinfo/infrastructures
>
--
Stephen G. Traugott (KG6HDQ)
UNIX/Linux Infrastructure Architect, TerraLuna LLC
stevegt@TerraLuna.Org
http://www.stevegt.com -- http://Infrastructures.Org