Too much has changes since this document was written - I'm not sure that any of it is still relevant. Maybe this file should be removed

StoryBoard incubator - stories

This document is a temporary store for stories that will be added to the Baserock Storyboard instance once it is available.


Paul: I'm quite positive about losing the Morph command, I dislike Morph and the word Morphologies. It seems we should deprecate the Morph command, have Git commands which implement the suggested workflow, and pursue IDE integration.

Morph commands as git sub-commands

(See this email thread)

  • 8 main commands (add-binary branch branch-from-morphology build cross-bootstrap deploy for-each upgrade)
  • 15 debugging / information commands

IDE Integration of 'morph' (or 'git sub-commands')

Most engineers now, if you take your GUI away from them, they are lost!


The terminology in Baserock is "fatal"

  • 'morphology' -> 'definition'
  • 'chunk' -> ??
  • 'stratum' -> 'Integration'? or something else?
  • 'system' -> 'assembly'? or something else?

morph build

(see this email thread)

  • Only one build command

    • Lose distbuild and build-morphology
    • Whether or not to build uncommitted changes is configurable according to --allow-uncommitted option
    • Issues:
      • Is it desirable - straycat believes distbuild 'make(s) the interface clearer. distbuild and build are distinctly different operations particularly with respect to the artifacts' destination: distbuild puts artifacts onto the trove, build stores artifacts locally.'
      • whether to do a local build or a distributed build
      • default value for --allow-uncommitted option
  • Build / Deploy via bootable disk

      > 17:01 < richard_maw> radiofree: it would be nice if one of our
      > developer workflows for dev-boards is 1. make a bootable disk, 2.
      > when you need to iterate, put the bootable disk back in your
      > deployment machine, rebuild and re-deploy on the same disk

Different branches of components from the same repo

(see this email thread )

Baserock does not currently support creating different branches of components that come from the same repo e.g Linux Kernel and Linux API headers. (This issue was identified in the assessment work I did back in July)

  • Is this a real use case? If so, do we want / need to fix it, and how?


Pete asks if reproducibility could be a stepping stone to updates

Provenance & Reproducibility

  • should always know Provenance whether or not we can reproduce
  • SPDX important part of provenance
  • Binary blobs still need provenance tracking.
  • Making the provenance of a system visible in a non-technical way.
  • Manifests?

bit-for-bit vs functionally equivalent

Rationalise upgrade functionality

This story is now in StoryBoard

It's currently possible to upgrade a system in the following ways:

  • setting the UPGRADE flag in the cluster morphology, in the environment or on the command line when calling morph deploy (this is deprecated, but still in place)
  • calling morph upgrade

We should remove the first option and report parse errors. The following irc snippet from #baserock gives some background

--- Day changed Wed Dec 03 2014

14:24 < petefoth> that’s an error too.
14:25 < petefoth> persia: I’m not sure I’ve fully grasped what you are
14:25 < persia> petefoth: Almost, but not quite.
14:25 < persia> Let me try again :)
14:25 < persia> If a user adds UPGRADE to a cluster definition, morph should
                 provide a parse error.
14:26 < persia> If morph is running in upgrade mode (either `morph upgrade` or
                `morph deploy --upgrade`, morph should unconditionally set
                UPGRADE to True, regardless of any user-provided settting.
14:26 < persia> If morph is running in deploy mode (`morph deploy` without
                "--upgrade"), morph should unconditionally set UPGRADE to False,
                regardless of any user-provided setting.
14:27 < persia>  /end conditionals
14:31 < petefoth> persia: the fog is lifting :) That does make sense to me. In
                  terms of documentation it should be doable too: the bulk of
                  the upgrade documentation is in ‘morph help upgrade’. ‘morph
                  help deploy’ mentions the ‘—upgrade option as an alternative
                  way of calling ‘morph upgrade’ and refers to ‘morph help
14:31 < petefoth> persia: I would only add, why not remove ‘morph deploy
                 —-upgrade’? we already say it’s deprecated: if the user wants
                 to upgrade use ‘morph upgrade’ *not* morph deploy
14:32 < persia> petefoth: In my mind, the use of UPGRADE is separate from the
                manner in which the user invokes upgrade.
14:32 < persia> Aside from that, I think I agree with you.
14:32 < petefoth> :)

Systems / Platforms


Support it!

Precedent from OpenStack is farming out changes to infrastructure that runs CI/CD on real hardware.

But not everyone has access to such infrastructure (even if it's in the cloud)

Non-Linux systems / targets

  • Android
  • AutoSAR
  • Integrity RTOS

We want reproducibility between heterogenous operating systems, since we got burned when we were reliant on one provider.

  • AIX
  • Solaris
  • QNX

Baserock in ... reference systems

  • Baserock in a Docker container
  • Baserock in Vagrant


Baserock is not a security solution, it is part of one as it provides provenance

  • reference systems, with security updates (no backports)
    • demonstrate recommended engineering practice (See also 'Process')


  • demonstrate recommended engineering practice
    • visible patch review, kanban, issue tracking
    • ci/cd of reference systems

User Documentation


Wiki pages are already good here. Also we made some videos which should be useful.

We have command-line help for command reference. We could'publish that somehow, but I'm not sure there's great value.

Config and Write extensions

Work on this story is complete - the documentation for extensions has been corrected and updated


Information in

A commentary on that might be useful, or just use the comments in the script


We already have quite a lot, but it could be organised better:

  • Quick guide

    • currently covers deploying, changing configuration
    • need to add installing, building and updating
  • Command details

    • Currently
    • need to extract the Command references from the descriptive stuff
  • Description

    • Currently in the Trove Reference Manual, needs to be separated
  • Need to address any changes needed in the Obstacles to deploying a Trove system

Import Tool


(See this email thread)

  • Rename tool (low priority)
  • Look into implementing as a Gearman worker (Medium priority)
  • Add functionality for tracking specific branches, authors or tags (Medium priority)


At the meetup on 2015-02-05 we talked about CI and CD in Baserock. Discussion on the mailing list led to the following actions being proposed:

  • Get Mason v3 merged, and carry out any further work it requires to be fully useful.
  • Deploy an instance of this Mason to work on patches submitted to our as-yet-unready Gerrit instance.
  • Decide which systems we want to test at this point, and check that this is consistent with the contents of clusters/ci.morph in definitions.
  • Decide on what to test in these systems.
  • Decide on a sensible way to define which tests are run on which systems - I think that having a "tests:" field in system definitions would be a good idea, where the content of this field is a list of test names that Mason can recognise.
  • Implement any tests that we want which don't yet exist.



Import tools

Definitions Browser

See this email thread

The required functionality may be achievable using a 'traditional' file browser application, or a simple dedicated 'chunk browser / explorer' GUI app might be needed. (dpenending on the outcome of th discussion on restructuring definitions in the '[RFC] YBD - proof-of-concept work for improving Baserock workflow' email thread)

Baserock on Bare Metal

Baserock out-of-the-box security

We are using Baserock for internet-facing infrastructure right now. It's good if people can deploy Baserock reference systems and have them be "secure by default."

We don't set a root password, by default, which is good.

From discussion in #baserock on 2015-01-09, the following things would also be good:

- PasswordAuthentication=no by default
- A default non-root user account, which is in sudoers
- Allow injecting a public key for that user at deploy-time, easily
  (we have cloud-config already, which seems a logical way to do this)
- PermitRootLogin=no by default (requires a default non-root user account and sudo)
- fail2ban present and enabled for any machine that faces the public internet