Baserock/ Baserock Glossary

Using Baserock

Community

Background

Baserock Glossary

  1. Artifact, build artifact
  2. Artifact cache server
  3. Base system
  4. Base system image
  5. Build system
  6. Build system image
  7. Btrfs
  8. Cache key
  9. Cache server
  10. Chunk, Chunk artifact
  11. Configuration extension
  12. Continuous integration and delivery
  13. Definition, definition file, morphology
  14. Deploy, deployment
  15. Deployment extension
  16. Development system
  17. Development system image
  18. Distributed build
  19. Git
  20. git cache server
  21. Gitano
  22. Local build
  23. Lorry
  24. Mason
  25. morph
  26. Morphology
  27. Staging area
  28. stratum (strata)
  29. System, System image, System artifact
  30. System branch
  31. Trebuchet
  32. Trove
  33. Workspace
  34. Write extension

Note: this document is work in progress, and is still subject to frequent change. If you are in any doubt over the meaning of a specific word or phrase, please ask in irc or on the mailing list.

Artifact, build artifact

The result of building something from source: a chunk, a stratum, or a system.

  • For a chunk, the source is the upstream source code plus a (possibly autogenerated, ephemeral) definition, and the result of the build (the chunk artifact) is what gets installed onto the system the chunk is part of.
  • For a stratum, the source is the definition, and the artifact is the list of chunk artifacts used for a build of a specific system.
  • For a system, the source is the definition, and the artifact is the files that are included in the system, plus any changes done at system building time.

Each artifact has a unique identity derived from its source code, build instructions and build environment, so that it can be shared.

Artifact cache server

A machine which can serve artifacts from its cache directory which is populated by morph. Allows morph instances on different machines to share artifacts, avoiding the need for everyone to build the same thing that someone else has already built.

See the caching page for more information.

Base system

A minimal Baserock system containing the minimum necessary to have a runnable system. Base systems are defined in definitions beginning with base-system- e.g. base-system-x86_64-generic.morph

Base system image

A system image of a Baserock base system.

Build system

A Baserock system containing the tools typically needed to build Baserock systems. Build systems are defined in definitions beginning with build-system- e.g. build-system-x86_64-generic.morph

Build system image

A system image of a Baserock build system.

Btrfs

A Linux filesystem, used by Baserock to provide the capability of versioning complete systems.

Cache key

This cache key is used to identify things in the build artifact cache, and to determine whether an artifact needs to be rebuilt. The cache key is computed for a source in a given context, and all the separate build artifacts built from that source in that context share the same cache key.

Cache server

See git cache server and artifact cache server.

Chunk, Chunk artifact

A component in a system that corresponds to an upstream project (e.g. the Linux kernel, systemd), or a component developed for Baserock itself.

Configuration extension

A deployment extension used to configure the system, e.g. by adding configuration files or entries in configurations to the system's rootfs. Implemented in a .configure file in the extensions/ directory in the definitions repository

Continuous integration and delivery

A software development process, where changes to projects are integrated into the mainline of development frequently, to reduce the difficulty of integrating changes later. Tools such as Jenkins have been invented to make this easier. (See also Mason.)

Definition, definition file, morphology

A data file used by the Baserock tools to specify how things are constructed or deployed:

  • a chunk definition specifies how a chunk gets built;
  • a stratum definition specifies what chunks to include in a stratum and where each chunk's source is stored;
  • a system definition lists the strata included in a system;
  • a cluster definition specifies how a group of systems is to be deployed together.

Deploy, deployment

A Baserock system artifact that has been built needs to be deployed to a real or virtual machine, or an OpenStack instance before it can be run. This is done using the morph deploy command. The deployment will configure the system to suit the particular target, by setting up the bootloader and hostname, configuring network access, filesystems, etc.

Deployment extension

A program or script which is invoked by morph deployduring the process of deploying a Baserock system. There are two types:

  • configuration extension;
  • write extension.

Development system

A Baserock system containing the tools typically used for developing under Baserock. Consists of a Build System with additional support for lanuguages including Ruby and Node.js. Development systems are defined in definitions beginning with devel-system- e.g. devel-system-x86_64-generic.morph

Development system image

A system image of a Baserock Development system.

Distributed build

A tool which allows some steps in building a system to be performed in parallel, and on machines other than the base or development system. (See also Local build and the distbuild guide).

Git

A distributed revision control and source code management (SCM) program. Used to in Baserock to store and provide version control of all system components.

git cache server

A server that allows querying of the git repositories without having to clone them. It is typically on the same machine as the Trove.

Gitano

The git server used in a Trove. See the gitano homepage

Local build

Performing a build on the build system or the development system rather than using the Distributed build tool.

Lorry

A tool which converts or mirrors upstream source code into git repositories on the Trove. A component of a Trove.

Mason

A continuous integration and delivery server which monitors git repositories for changes to any components of the system(s) being developed, builds all the necessary artifacts, and tests them using a battery of automated tests. There are public examples for the Baserock project at Mason x86_64 and Mason armv7lf

morph

The morph program is the workflow, build, branching, and deployment tool that is used when developing with Baserock. The word 'morph' is also often used to refer to a definition (or morphology ), which has the extension .morph.

Morphology

See definition.

Staging area

A directory where intermediate build artifacts are stored and assembled temporarily while building, before they are deployed. The directory exists:

  • in the development system for local builds;
  • in build worker nodes for distributed builds.

(This entry should be improved sometime)

stratum (strata)

A group of chunks that together serve some unified purpose. For example, a stratum might contain a set of chunks for running a mail server, or chunks for all the version control systems we support in Trove. A special case is the build-essential stratum, which is the set of chunks which are enough to build all the rest of Baserock.

The plural form of stratum is strata. Blame the ancient Romans. One stratum, many strata.

Strata form "super-components", bigger building blocks which make it easy to build entire systems. If chunks are individual red bricks, strata are pre-fabricated concrete walls and floors.

Strata definitions are stored in the strata directory of the definitions git repository.

System, System image, System artifact

In Baserock, a system is a set of strata that work together for some purpose. A system is not ready to run on a device or virtulization host, it needs to be deployed to a machine (real or virtual) first.

Can be deployed and run as a Virtual Machine in a virtualization tool such as VirtualBox or KVM (see Quick Start).

System branch

A Git branch in definitions.git is effectively a branch of an entire system, rather than one component, as the definitions.git repo controls what components and what version of each component goes into a system.

Old versions of Morph treated branches of the definitions.git repo specially, and had its own set of commands for working with them. Since Baserock 15.25, you should use normal Git commands when working in definitions.git, just like other repos.

Trebuchet

(This entry needs further work - Trebuchet does not exist as a standalone program, only the referenced commands).

A tool which provides a generic update mechanism for a Linux system. It delivers updates through a binary patch for the filesystem. This helps to optimise the network bandwidth requirements of doing an upgrade of a Baserock system. It is similar to rsync, when run in batch mode, but more efficient in our use cases. (It is also much less featureful than rsync.)

It provides the following commands (invoke them with the --help option in your development system to see what each one does):

    tb-switch tb-update tbdiff-create tbdiff-deploy

Trebuchet is not used much, yet.

Trove

A server that provides git hosting, mirroring and conversion of upstream source code into git, build artifact storage, and other services that are useful to a team using Baserock to develop products.

Workspace

Old versions of Morph (before the Baserock 15.25 release) had a concept of the "workspace", where all Git clones in use by Morph must be kept. Morph no longer requires or supports the concept of a 'workspace', any Git clone can be used.

Write extension

A deployment extension used to perform the deployment e.g. by copying a VM disk image somewhere and starting the VM. Implemented in a .write file in the extensions/ directory in the definitions repository May also include a '.check' file which contains preparatory checks for the write extension.