eclipse / kuksa.apps

Kuksa Apps repo

THIS REPOSITORY HAS BEEN ARCHIVED, see issue 42 for details.

Kuksa-Apps Repo

This repository constains application use-cases used along with the Eclipse Kuksa environment to be distributed along with the appstore, hawkBit, and the invehicle platform.

kuksa.apps's Issues

Cloud-mechanic incompatible with newer GCC

we should start to use up-to-date software. Building the cloud-mechanic still yields a ton of warnings. Everyone using a compiler released after 2016 wont be able to build apps, and we can't just continue using gcc 6 forever.
I know warning != errors, but this issue is known ~2 years now.

APP-Publisher does not conform to our Docker-standards

docker-images should yield the prefix DOCKER_ or SIMPLE_ to indicate if they are docker or python applications.

Regardless of this, the kuksa-app-publisher generates tape-archives missing these prefixes.

Message:

/tmp/<target>/Kuksa-Traccar-0.1.0.tar
I do not quite know what to do with this, so I will just download
Download only
Done: 200

Manually named images work as intended

tmp/<target>/DOCKER_appmanager.tar
Careful analysis and extensive checks have revealed this to be a docker image. Yummy
Trying to deploy docker image in /tmp/<target>/DOCKER_appmanager.tar
Image imported: Loaded image ID: sha256:xyz
Trying to start image sha256:xyz

Apps hard-coded App-store / HawkBit IP error

Appstore

All apps currently expect an instance of the appstore on localhost:8082 this should be changed to the real Appstore

AGL does not ship with an local app-store so this config won't work on the dedicated hardware

HawkBit

all apps currently also yield the incorrect IPs for the HawkBit service.

raise ConnectionError(e, request=request)
requests.exceptions.ConnectionError: HTTPConnectionPool(host='11.11.111.11', port=8080): Max retries exceeded with 
 (Caused by NewConnectionError: Failed to establish a new connection: [Errno 101] Network is unreachable',))

EDIT: deleted links since they are a hazard

APP-Publisher borked naming-convention

The kuksa-app-publisher reads the name-field of the app and tags the docker-image with the given name.

e.g. 0.1.0__Kuksa-Traccar-0.1.0 or 0.1.0__Dashboard-0.1.0

This works for the apps mentioned in the example above, however, when trying to build the cloud-mechanic the following error occurs:

Error parsing reference: "xyz__Cloud-Mechanic-0.1.0" is not a valid repository/tag: invalid reference format: repository name must be lowercase

What is correct in this situation?

Incompatibility with Boost version 1.71

FYI:
According to kuksa.apps/invehicle-apps/sensoris.invehicle/README.md, the boost version for "sensoris-invehicle" is proposed to be higher than 1.67.
I tried it with the Boost version 1.71 and it doesn't work, because the "Boost.Beast.Buffer" doesn't exist in 1.71.

Mixed APP-Instructions

The invehicle-apps have different ways of building, deploying and environment-variable-handling.
In order to test the Apps we need to know, which Application yields the correct way to build and deploy.

Some examples listed in the GIT aren't even compatible with the current AGL-Image

Dashboard - weird build behaviour

Sometimes when building the kuksa-cloud-dashboard the following error is encountered:
build.sh: 68: build.sh: Syntax error: "}" unexpected, although this bracket marks the closing function.

The script executes as normal but builds slightly corrupted docker-images

App-Publisher ignores newapp-Flag

Inside the YAML- File a the newapp-flag exists to differentiate between new releases and updates. However, the flag is ignored and always set to false, which prevents new apps from being uploaded.

Invalid architecture in build-script

The new version of the Raspberry-Pi image seems to be arm32v7:

uname -a : Linux raspberrypi3 4.9.80 #1 SMP armv7l armv7l armv7l GNU/Linux
But the current build-script only allows arm32v6 to be compiled.
This yields no immidiate issue, but will in the future and should be updated with newer raspi-versions

Error building docker image kuksa-cloud-dashboard

I am trying to build docker iamge of kuksa-cloud-dashboard.

./build.sh amd64
unknown flag: --platform

I have set experimental on Docker and restarted.

Traccar Docker last layer corruption

On certain AMR64 platforms there seems to be a problem with the two stage docker build when using Python: Once python touches its files (the service is run once), after the container is stopped (gracefully or forcefully), all files in the last layer are gone i.e. all python source and all packages. -> Container can't be started again

Not dependant on a specific docker version 8treid different) not dependant on python version (tried 3.5...3,7) not dependant on Alpine/muslc (tried glibc/debian)

This does NOT happen on amd64 and arm32 builds

Deprecated functions in App-Publisher

yaml.load(__config_file) should be replaced with yaml.load(__config_file, Loader=yaml.FullLoader) to conform to newer standards and eliminate errors

Move Traccar docker to arm32v7

armhf is deprecated, traccar docker should be moved to arm32v7 while upgrading the alpine version....

Will do this after verifying datalogger-mqtt is fine on AGL-Pi (it is already on alpine 3.8 arm32v7, but not yet tested)

APP-Publisher uses wrong protocol (http instead of https)

the new HawkBit server uses https rather than simple http

In order to function with the new HawkBit, change the following lines
Line 137: response = requests.post('http://

and
Line 173: response = requests.post('http://

inside the publisher to read https instead of http to fix the issue

Network settings

The YAML-Example has marginal documentation.
Any further explanation on these parameters?

network_mode : "NETWORK SETTINGS"

• available parameters
• mandatory parameters
• optional parameters
• formatting example

Would be a helpful addition to the README

Get rid of 3rd-party-lib folder

Currently, the code of 3rd party libraries is in the 3d-party-libs folder. This was the simplest and fastest approach to provide the apps for the time being. We need a better solution to ease maintenance, updatability, etc.

Building Cloud-mechanic fails

Building with ./build.sh arm32v6 fails due to:

Step 13/19 : COPY --from=build-env /app/remoteAccess/build/remoteAccess /
COPY failed: stat /var/lib/docker/overlay2/<ID>/merged/app/remoteAccess/build/remoteAccess: 
no such file or directory

Discussion on archiving kuksa.apps repo

Hi KUKSA Community,

The KUKSA apps repository hasn't seen activity for quite some time. Most of the development has shifted to other repositories or the KUKSA project such as kuksa.val and kuksa.feeders. We would therefore like to take this opportunity to start a discussion on how to further proceed with this repository. As the apps repository is not used in other parts (eg. kuksa.val) of the KUKSA project anymore, we would suggest to archive the apps repository (https://github.com/eclipse/kuksa.apps).

Please comment on this issue so we can come to a conclusion on how to further proceed.

App-Publisher never re-publishes

Publishing an App using

1. -n Flag = publish new

Category: 354
error Hawkbit connection error. Check your Hawkbit's IP in the propreties file!
App already exists in the appstore. Therefore no new app created.
{'content': [], 'total': 0, 'size': 0}
No app with the passed name found in Hawkbit.

not creating app because it already exists? The only existing data is the category of the app, which was added to the app-store some operations ago. The publisher still builds a Dockerfile and saves it locally

2. -r flag = update app

No app with the passed name found in Hawkbit.

not updating app , even if -n returned an error, because the app already exists

---

Appanrently has the same origin as this app-store-issue

App-Publisher hard-coded architecture errors

The apps can be built for amd or arm32vX and images are automatically tagged as such.
e.g. arm32v6/kuksa-traccar:0.1.0 (arch/name:version)

However, the publisher looks for those parameters in the yaml-config file. The Traccar-config yields the wrong architecture, which results in an error.

[App-Store] Validate if app name is ok before category is created

The kuksa-publisher.py creates an category (line 154) within the App-Store even if creating the app fails (line 171). For both category and app names should be valitaded before creating them.