...

Architecture Overview

Markdown Notes

WIP Notes:

OCI Bundle Gen Use Cases (1)

Rewrite these as User Stories

1. As an Operator I want to be able 

used in STB

expected to be on Cloud

Extendable architecture

Requirements (2)

• Read in OCI_Image
• Read in template for a target STB (format TBC)
• Output a minimal OCI bundle* suitable for execution on target STB
  • FS system
  • runtime Config.json
• Apply operator restrictions based 

Summary

An overview of Bundle gen in context

draw.io Diagram
border true diagramName OCI Bundle Gen Processing simpleViewer false width links auto tbstyle top lbox true diagramWidth 911 revision 1

Requirements & Use Cases

• Convert OCI images generated by the Firebolt SDK into a lightweight, minimal OCI bundle specific to a device that can be run by Dobby on the STB
  • In traditional container solutions (Docker, Podman), this stage is performed by the container runtime itself.
• Parse the OCI Image Manifest/Configuration files to build the final bundle
• Expected to be used both in a cloud environment and on a development machine
  • Unlikely to be used on a STB
• Generated bundles must be able to run on a local machine/STB for use during application development
• Allow creating configuration files per DAC compatible device.
  • This will allow BundleGenerator to generate bundles that will work on a device without having access to that device's hardware/build environment
    

• Allow creating operator configurations to apply business logic to a container image file across all platforms.

• Support hardware variants/revisions of the same platform (e.g. Xi6-A and Xi6-T)

• Process an extended "application capabilities" section to add/remove/change specific sections of the generated bundle according to application requirements

• Prevent creating a bundle for an incompatible device.

  • If the device does not support the required RDK release, then the image cannot be run on that device.

  • However, aim to ensure broad compatibility of applications. The goal of running containerised apps is to allow applications to not be concerned about the platform they are running on

• Allow processing stages to be extended as necessary

Inputs

OCI Image

Description

OCI Image - generated locally or pulled from an OCI Registry

Format

• Directory storing the manifest, layer tarballs and signatures as individual files. Useful for quick debugging of a newly generated image locally (for developer using the SDK)

• OCI Image Layout Path - An image tag in a directory compliant with "Open Container Image Layout Specification" at a given path. See https://github.com/opencontainers/image-spec/blob/master/image-layout.md for more details

  • Allow optionally passing in tag to use a specific tagged image version. Default to latest

Platform Template/Configuration

Description

The template would contain information specific to a single RDK hardware platform/revision. The SDK would ship with configurations for common reference devices such as the Raspberry Pi, Emulator and x86.

Format

Exact format TBD. Potential formats include

• JSON configuration file
• Tarball of device rootfs + config file
• Tarball of specific directories from device + config file
• OCI Image Layer (could then be used as a base layer to build a new image on top of, specific for the device)

Information likely to be required in the template/config would include:

• Device name

• Architecture

• RDK Version (2020Q1, 2020Q2 etc)

  • Include available/installed RDK Services (Thunder NanoServices)

  • Could have multiple configurations for the same device but for different RDK releases if different versions are in use in the field

• GPU Device nodes (and similar - e.g. VPU) that need to be mapped inside the container if graphics is needed

• GPU Libraries

  • Set of tuples containing libraries that must be automatically mounted inside the container for graphics support

  • This allows for adding custom, platform specific graphics libraries into containers (for example libnexus on broadcom platforms)

  • These mounts will override any graphics libraries included with the application

• General Libraries

  • A list of all the libraries available on the device. This will be used when converting the image to bundle to reduce the size of the final output by bind mounting in libraries that are the same major version in the image and on the device

  • This section must be automatically generated for a platform

  • It should be possible for a developer to force the use of a library minor version (e.g. libFoo.so.2.1.5). In this case, unless that exact minor version is available on the STB, the version in the image will be used

    • The mechanism for this should be exposed in the STB publishing tools

• Custom files/paths that must be bind mounted inside the container

• Maximum amount of RAM an application can use (maybe just the amount of RAM available on the platform?)

• Supported resolutions (1080p, 4k)

• Supported Networking options

• Custom environment variables that must be set, specific for the platform

  • XDG_DATA_DIRS

  • XDG_RUNTIME_DIR

• Users/Groups

  • Containerised apps should run as a unique user and group. Define what users/groups a container should run in

  • Allow specifying a range: e.g. AppUser[0-99]:AppGroup

• Non-standard mappings

  • Across RDK, many paths and file names are standardised across builds. If the device uses any non-standard paths or devices, this set of tuples can override the defaults.

Markdown Notes

WIP Notes:

Summary

An overview of Bundle gen in context draw.io DiagrambordertruediagramNameOCI Bundle GensimpleViewerfalsewidthlinksautotbstyletoplboxtruediagramWidth691revision1 draw.io DiagrambordertruediagramNameOCI Bundle Gen ProcessingsimpleViewerfalsewidthlinksautotbstyletoplboxtruediagramWidth911revision1

STB Specific Template (3)

...