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.

StoryBoard incubator - stories
Workflows
Systems / Platforms
Security
Process
User Documentation
Firehose
CI/CD
Ceph
Chef
Import tools
Baserock on Bare Metal
Baserock out-of-the-box security

Workflows

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!

Terminology

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?

Reproducibility

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
                  suggesting.
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
                  upgrade’.
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

Cross-compile

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

Security

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')

Process

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

User Documentation

`morph`

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

Mason

Information in http://git.baserock.org/cgit/baserock/baserock/definitions.git/tree/mason/mason-generator.sh

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

Trove

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
  - command-line help for Lorry, Trove and git commands?
  - Trove Reference Manual
- 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

a README, that can be referenced from the wiki - Done see http://git.baserock.org/cgit/baserock/baserock/import.git/tree/README
a tutorial on the wiki, focussing on Chef, that shows what sort of 'hand-dirtying' is involved - there are guides on the wiki though they don't cover Chef
each will include links to the other
- Link from 'Using the Baserock Import tool' wiki page to README
- a link from the README to the wiki guides needs to be added. (Not sure which StoryBoard project to use for this 'story')

Firehose

(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)

CI/CD

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.

Ceph

Chef

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