The GitHub validation workflow should be executed on changes in the kirkstone branch as well.

The recipe should be able to:

• build Kanto Azure Connector from sources
• integrate the related resources: service file, configuration, certificates etc.
• support various platforms/architectures

Problem: The storage directory for file-backup needs to be specified in /etc/file-backup/config.json because the default location is causing the service to fail to start on Fedora IOT.

Suggested solution: Specify a default storage location in file-backup.conf. The suggested location is "storage": "/var/lib/file-backup" in /etc/file-backup/config.json, which is probably recipes-management/file-backup/files/config.json in this repository.

Dunfell has Long Term Support and it'll improve the project adoption. In the same way as it was implemented for Kirkstone, we need a new branch (called dunfell) where all recipes will be adopted. Note that the adoption will require a bunch of updates because Kirstone introduced some language changes:

• Release notes for 4.0 (kirkstone)
• Migration notes for 4.0 (kirkstone)

The recipe should be able to:

• build Kanto File Upload from sources
• integrate the related resources: service file and configuration
• support various platforms/architectures

The recipe should be able to:

• build Kanto Local Digital Twins from sources
• integrate the related resources: service file and configuration
• support various platforms/architectures

It has to be incorporated as it's described in:

• eclipse-kanto/kanto#168

The recipe should be able to:

• build Kanto System Metrics from sources
• integrate the related resources: service file and configuration
• support various platforms/architectures

The following has to be available:

• a Kirkstone-dedicated branch - i.e. kirkstone
• a tag in the branch that references the layer with a fixed SRCREV to the released Kanto v0.1.0-M4 version
• ensure the recipes are switched back to the main branch after tagging

The recipe should be able to:

• build Kanto Update Manager from sources
• integrate the related resources: service file and configuration
• support various platforms/architectures

The recipe should be able to:

• build Kanto Software Update from sources
• integrate the related resources: service file and configuration
• support various platforms/architectures

Issue description

The Container Management recipe uses ${AUTOREV} thus pulling the latest commit from container-management. This now fails to compile for Leda-Distro which is based on kirkstone.

The full recipe log can be found here:
kanto_cm_compile_failure.log

The lines containing the failure:

HASH subkey 7ebe85e22f308a2556eb2dce4f9d611c371d0064f995533f6a3ed8738e9bf1ee "stdout" = 67c71b5ad3badf4147a7ac7cfaa2eacf4017d1f060a8b3dae9415254e28cfcc1
# github.com/docker/docker/libnetwork/networkdb
../../../../pkg/mod/github.com/moby/[email protected]+incompatible/libnetwork/networkdb/networkdb.go:149:16: undefined: atomic.Int64
../../../../pkg/mod/github.com/moby/[email protected]+incompatible/libnetwork/networkdb/networkdb.go:154:16: undefined: atomic.Int64
HASH subkey f8474e3cf420c317c9d2d8bcc1224e1d7bf857bcc9d01cdbb952715199e5dd60 "link-stdout" = d096858d49809339f49411b2867f7ff73433ab348a826577d56fd45a24739b1c
WARNING: exit code 2 from a shell command.

The issue seems to be connected to bump in the moby version: eclipse-kanto/container-management#146

Workaround for Leda

In meta-leda we have opted for our 0.1.0-M1-release to use a fixed known-good commit hash for CM.

Steps to reproduce:

1. Checkout https://github.com/eclipse-leda/leda-distro (branch 0.1.0-M1)
2. Following the leda-documentation setup an environment where you can build Leda 0.1.0-M1 with kas.
3. Run kas checkout kas/leda-qemux86-64.yaml
4. Comment out in meta-leda/meta-leda-components/recipes-sdv/eclipse-kanto/container-management_%.bbappend the L24: SRCREV="65e00358fa5aed1792059488a80fe755b36a8191"
5. Run: kas shell kas/leda-qemux86-64.yaml -c 'bitbake container-management' (to only run the CM recipe) or kas build kas/leda-qemux86-64.yaml (to run a full Leda-distro build)

Kanto Update Manager recipe has to be updated in regards to the following changes:

• binary name is changed from update-manager to kanto-update-manager
• service name is changed from update-manager.service to kanto-update-manager.service
• agent name is removed from update manager configuration due to duplication

Use the following issues for reference:
eclipse-kanto/update-manager#36
eclipse-kanto/update-manager#38

The recipe should be able to:

• build Kanto AWS Connector from sources
• integrate the related resources: service file, configuration, certificates etc.
• support various platforms/architectures

The recipe should be able to:

• build Kanto Container Management from sources
• integrate the related resources: service file and configuration
• support various platforms/architectures

Currently, system-metrics.inc is using: Eclipse Kanto System Metrics but all other recipes are using lower case for the component name i.e. it should become: Eclipse Kanto system metrics

Currently, it's: @SM_LOG_DD@/system-metrics/log.txt but it should be: @SM_LOG_DD@/system-metrics/system-metrics.log

The change will happen with eclipse-kanto/suite-connector#28. Correct Yocto recipes for:

• Kanto Local digital twins
• Kanto Suite bootstrapping
• Kanto Suite connector

The recipe should be able to:

• build Kanto Suite Bootstrapping from sources
• integrate the related resources: service file and configuration
• support various platforms/architectures

The available integration tests per Kanto component must be run against an image built using the respective recipes from the Yocto meta layer.

Depending on the duration for the tests execution - environment setup, test image build, tests execution, etc. it has to be decided on what basis these integration tests should run - per PR, nightly, etc.

Yocto recipes (.bb files) contain information about a single piece of software:

• source code repository
• patches
• configurations
• compile instructions
• packaging

Every Kanto component requires own recipe to be a part of the Yocto build.

Tasks

• #1
• #3
• #4
• #5
• #6
• #7
• #8
• #23

Issue

The update manager recipe compiles and installs the UM config.json and binary in the final image, but the service unit fails to start the service. Looking at the logs, we can see the following error:

Jul 27 08:25:40 qemux86-64 systemd[1]: Stopped Eclipse Kanto - Update Manager.
Jul 27 08:25:40 qemux86-64 systemd[1]: Started Eclipse Kanto - Update Manager.
Jul 27 08:25:41 qemux86-64 update-manager[347]: flag provided but not defined: -configFile

Comparing the error log and the help of UM we can see there is an error in the service unit template here:
https://github.com/eclipse-kanto/meta-kanto/blob/kirkstone/recipes-management/update-manager/files/service.template#L10

Currently L10 is:

ExecStart=@UM_BIN_DD@/update-manager -configFile @UM_CFG_DD@/update-manager/config.json

But should be:

ExecStart=@UM_BIN_DD@/update-manager -config-file @UM_CFG_DD@/update-manager/config.json

That is, the option name is -config-file and not -configFile.

Expected Behavior

The service unit is patched with the proper option name and it starts successfully.

The recipe should be able to:

• build Kanto Suite Connector from sources
• integrate the related resources: service file, configuration, certificates etc.
• support various platforms/architectures

It has to be incorporated as it's described in:

• eclipse-kanto/kanto#165

we are trying to integrate kanto recipes in yocto below are some details:

• using meta-kanto (branch: main)
• default go package version 1.16.7 (updated to new version 1.19.7)

while integrating recipes , we are facing downloading issue with some go modules:
Error:
containerm/ctr/ctrd_metrics_util.go:17:2: github.com/containerd/[email protected]: Get https://proxy.golang.org/github.com/containerd/cgroups/@v/v1.0.4.zip: dial tcp: lookup proxy.golang.org: no such host

containerm/ctr/ctrd_cache.go:21:2: github.com/containerd/[email protected]: Get https://proxy.golang.org/github.com/containerd/containerd/@v/v1.6.18.zip: dial tcp: lookup proxy.golang.org: no such host

could you help us to fix this issue:

The Eclipse Kanto project is currently restructuring its license scheme - from Eclipse Public License 2.0 only to dual licensing under Eclipse Public License 2.0 and Apache License 2.0 (you can read more about it here).

The following changes must be applied to all project repositories:

• Update the LICENSE file to be compliant with the format recommended by Eclipse:

This program and the accompanying materials are made available under the
terms of the Eclipse Public License 2.0 which is available at
https://www.eclipse.org/legal/epl-2.0, or the Apache Software License
2.0 which is available at https://www.apache.org/licenses/LICENSE-2.0.

... Text of the Eclipse Public License 2.0 ...

... Text of the Apache Software License 2.0 ...

• Update the Declared Project Licenses section of the NOTICE.md file with the new license information, i.e.:

This program and the accompanying materials are made available under the terms
of the Eclipse Public License 2.0 which is available at
https://www.eclipse.org/legal/epl-2.0, or the Apache License, Version 2.0 which
is available at https://www.apache.org/licenses/LICENSE-2.0.

SPDX-License-Identifier: EPL-2.0 OR Apache-2.0

• Update all Yocto recipes according to the new project's licensing scheme, i.e.:

LICENSE = "EPL-2.0 | Apache-2.0"
LIC_FILES_CHKSUM = "file://src/${GO_IMPORT}/LICENSE;md5=<new md5 checksum>"

The recipe should be able to:

• build Kanto AWS Connector from sources
• integrate the related resources: service file, configuration, certificates etc.
• support various platforms/architectures

Kanto Update Manager recipe has to be updated in regards to the following changes:

• binary name is changed from update-manager to kanto-update-manager
• service name is changed from update-manager.service to kanto-update-manager.service
• agent name is removed from update manager configuration due to duplication

Use the following issues for reference:
eclipse-kanto/update-manager#36
eclipse-kanto/update-manager#38

The recipe should be able to:

• build Kanto File Backup from sources
• integrate the related resources: service file, configuration, certificates etc.
• support various platforms/architectures

The recipe uses an .inc mechanism to ensure all aspects of the Kanto Suite Connector behavior are easily configurable via a .bbappend.

All major aspects are currently covered there except the desired logs storage location for the component. It should made configurable aligned with the adopted configuration approach for the recipe.

Langdale is the last Yocto release and as such, the main branch has to be updated to cover it:

• Release notes for 4.1 (langdale)
• Migration notes for 4.1 (langdale)

The last Go version is set in the parent feature. Based on it, these steps have to be executed:

• check for potential updates from go mod tidy
• check the component build
• check that all tools from the validation flow will pass
• update the Go version in the GitHub validation flow
• update the Go version in the notice file
• if required, update the related libraries in the notice file

The following has to be available:

• a tag in the branch that references the layer with a fixed SRCREV to the released Kanto v0.1.0-M4 version
• ensure the recipes are switched back to the main branch after tagging

The following has to be available:

• a Kirkstone-dedicated branch - i.e. kirkstone
• a tag in the branch that references the layer with a fixed SRCREV to the released Kanto v0.1.0-M2 version
• ensure the recipes are switched back to the main branch after tagging

The GitHub workflow should be adapted to use the latest Yocto release, which is mickledore

Since [#54] is completed the workflow now should also be added in the kirkstone branch itself in order the validation to work correctly.

See
https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS#LTS_.E2.80.9CMixin.E2.80.9D_repositories
and
https://git.yoctoproject.org/meta-lts-mixins
Check if we can use this for our kirkstone branch to build the most recent revision of container management.

Currently, the default configuration of the recipe sets the SC_CFG_DD to "${sysconfdir}", i.e. /etc.
The value later used to populate the templates must be preserved as-is configured by the user or default to ensure ease of use and not implicitly extended with a /suite-connector suffix by the recipe.

The systemd and binary templated configurations must be updated accordingly to refer the suite-connector subdirectory in SC_CFG_DD to load the respective configurations.

Great to see a Yocto layer for Kanto supporting the Kirkstone LTS release.

It would be great if meta-kanto would also be compatible with the current Dunfell LTS release, as many existing device manufacturers tend to have not yet updated.

Also preparing for the next LTS (Langdale) would be good.

Tasks

• #47
• #48