Intro

The job of the BundleGenerator is to produce from a SoC-agnostic oci Application Container Image a so called "bundle" or also refered to as "bundle-image". This bundle-image contains those same Application binaries (*) but now also a container run config (see dobby / oci runtime-spec config).

...

(*) = same Application Binaries : Depending on how you configure the bundlegenerator it could also remove some binaries (and replace them with bind mounts from associated files on rootfs) to optimize size but this has big disadvantage that you will introduce much stricter dependencies of the bundles on specific firmware version, move away from self-sufficient & portabilty goal and in practice lose your independence of STB host rootfs/firmware version, need to recheck apps upon each firmware upgrade, we will not do that, is against scaling of binary compatible DAC & Appstore.

stbBundleTemplate.tgz

The CPE team is responsible for generating the stbBundleTemplate.tgz for the relevant platforms and naming them correctly according to naming convention explained in this section

...

Below you can find the definition and further naming convention of {platformName} and {dacBundleFirmwareCompatibilityKey}

platformName

Since bundles are CPE model/platform specific we need to define the names of these models/platforms in DAC cloud platform/ASMS and use the appropriate platformName when we want to get such bundle.

...

The STB can based on this config, retrieve platformName to be used towards DAC cloud by retrieving the "dacBundlePlatformNameOverride" value from LISA#lisa.dac.confg

dacBundleFirmwareCompatibilityKey

To indicate the compatibility of a bundle with set or series of firmware versions of a given platform a dacBundleFirmwareCompatibilityKey key/value is introduced.

...

The STB can retrieve the "dacBundleFirmwareCompatibilityKey" configured in its firmware version from LISA. See use getMetadata {"type":"application/LISA", "id":"lisa.dac.confg", "version":"0"} in LISA#lisa.dac.confg

Flow of generation/updating dacBundleFirmwareCompatibilityKey 

Generation of this dacPlatformFWCompatibleBundleVersion is being done manually by CPE team using hash script https://github.com/stagingrdkm/lgpriv/blob/1deb05c8a5a1c3d3e78a00f8fc47f8e2844b8cf8/lg_platform_templates/oe_3.1/calc_hashes.sh on stbDacContainerConfig and stbDacLibs files, latter file is generated together the firmware image creation. 

CPE team needs to then create associated stbBundleTemplate.tgz ( {platformName}-{dacBundleFirmwareCompatibilityKey}_dac_configs.tgz )  and distributed to DAC cloud team for them to add to bundlegenerator service. For now this creation and distribution is manual job by CPE team for each platform. Later on we can look at automating this with jenkins.

retrieve dacBundleFirmwareCompatibilityKey

ResidentApp/STB can retrieve the "dacBundleFirmwareCompatibilityKey" configured in its firmware version using LISA API getMetadata {"type":"application/LISA", "id":"lisa.dac.confg", "version":"0"} see info in LISA#lisa.dac.confg

(on condition it is configured in LISA as part of its LISA thunder config).

git location of STB templates

At the moment (in this startup phase) the templates are stored in https://github.com/stagingrdkm/lgpub/tree/master/dac/templates

...