Skip to content

Home

Jump to bottom
chris grzegorczyk edited this page Oct 16, 2012 · 60 revisions

Here you will find technical documents which support the evaluation, planning, and implementation of features in Eucalyptus.

Eucalyptus Architecture

This the canonical reference for two classes of documents: feature specifications used in planning releases and generational design documents which evolve iteratively with the ongoing implementation of the system. This page serves the presentation and navigation of all the documents from the underlying repository with the raw materials. The purpose of the documents aggregated here is to provide the needed technical specifications, background, analysis, and record of architecturally significant decisions in support of the development of all new features in Eucalyptus.

Table of Contents

Convenient short cuts go here...

Find me all the things...
in a certain release 2.0
pending 		3.0
pending 		3.1
pending 		3.2 3.3
pending

Where else might I look...

To find documentation please also see:

tag:index

What it is used for...

The purpose of the documents aggregated here is to support the development of new features in Eucalyptus. To that end, they play a role in several stages of the development process:

  1. Feature specification: associated with each feature is an overall document describing the important technical characteristics in a release (or generation) independent fashion. These reflect the understanding of the feature which is used in subsequent steps.
  2. Scope & Estimation: prior to release planning a technical assessment is made about the aspects of functionality to go into a generation of the feature. The spec documents which are associated with a release start life at that time. These subsequently evolve until they have been committed to for a particular release (but may be present even when not committed to a release).
  3. Design & Implementation: a feature which has been committed to a release is supported by a design document for that release. The design documents start their life when work towards that release does. These subsequently evolve until work stops for that release of the feature. (They would then be ported forward to the final documentation).

What you will find here...

There are two classes of documents which you can expect to find the authoritative copy of here: feature specifications used in planning/estimation of releases and generational design documents which evolve iteratively with the ongoing implementation of the system.

Feature Specification documents are statements of our intentions, understanding, and long-term scope:

  • are "timeless" in that they are overarching and meant to be definitive of the feature overall.
  • evolve over time independent of the features current implementation status.
  • reflect our current understanding of the features definition in the broadest sense.
Feature Specification documents consist of:
  • Specification: overall technical specification of the functional and architectural/quality characteristics.
  • High level design/Architecture: definition of fundamental components, interfaces, behaviours including information, control, and concurrency models.
  • Supporting Documents: API/Service specifications, client tool chains, WSDLs, TCKs.
Generational Documents are specific to a release and meant to serve the tasks surrounding the planning, design, implementation, and delivery of a feature.
  • support the scoping, design, and implementation effort of the feature during that release.
  • defining the design and implementation objectives and details for a particular version of a feature.
  • specific to the context and determined by the constraints of a particular release time frame.
  • change as needed to support the above objectives and are quiesced after those tasks are completed.
Generational documents consist of:
  • Functional requirements: as identified by a corresponding epic in JIRA
  • Specification: release-specific technical interpretation of functional requirements
  • Designs: release-specific design models and descriptions, starting with just-enough and co-evolving with the implementation.
Clone this wiki locally