eclipse-leda / leda-utils Goto Github PK

During development, eg when creating lots of container instances, a manual pruning may become necessary. As long as the container runtime is not tuned for that use case, the leftovers will fill the disk pretty fast, when the developers is doing a lot of trial&error deployments without cleaning up old container instances up front.

One user reported:
• Is there any command for pruning all the containers? I see in the cheat sheet this command - nerdctl system prune –all. But it doesn’t work. I could not find any appropriate documentation in Kanto-CM as well. For some reason, after running and re-running this container a few times, the disk space has become full, and the containers are bloated

nerdctl was planned to be installed in Leda and work on top of containerd directly. If this is not properly working, it may be necessary to do the following:

• Adapt the kanto-cm configuration to clean up and throw away garbage containers much faster, esp. during development
• Add a container-pruning utility to leda-utils

When looking at logs from a container within a qemu instance, the screen updates are rather slow and jumping down to the end of a container log takes some time.

It would be great if the "Show logs" feature would jump to the end of the logfile automatically (tail).

In case i need to know the root cause of a problem or error message, then I can scroll up. But usually, i start at the end to see the latest messages.

Would also be great if HOME / END buttons would be working.

And lastly, the "Container Logs" dialog should be closed also when i press ESC. Right now, it only closes when i hit ENTER (to pres the OK button).

Add the ability for kantui to follow logs

Background
Eclipse Kanto Container Management recently implemented the automated initial deployment of containers based on json manifests. Integrators can define the "init_dirs" configuration property and kanto-cm will take care of creating and starting the containers when the service starts.

Initially, kanto-auto-deployer (KAD) in leda-utils was meant to be that feature. Now, it became obsolete. But we can implement more convenient features in KAD which will probably not be implemented in kanto-cm (as they're not for production use), to make reuse of the code.

File change watchdog
Whenever a json manifest changes on disk (e.g. newly created, or touched/updated), KAD will delete the corresponding container and recreate it with the new settings. These will for example allow to add or change environment variables for a containerized process and KAD can automatically recreate the container. Kanto-cm would not pick up these changes, as in a production environment, such manual file changes are not be expected.

Note: For framing this idea, other features for KAD may be: auto-delete duplicate containers based on name, import container images from filesystem for offline installation ("AirGap")

While modifying kanto-cm deployment descriptors (eg cloudconnector.json), i often had to redeploy the container (remove and recreate), so that environment variable and mount point changes are applied.

It would be great if kantui could help me to recreate the container, e.g. by offering a hotkey for "systemctl restart kanto-auto-deployer".

I know it introduces a dependency from kantui to kanto-auto-deployer (and systemd in this case), but maybe it can be configured as a customizable hotkey configuration or so.

When controlling the configuration file of Eclipse Kanto Container Manager with sdv-kanto-ctl, there is an option to set a primitive value (set-value). However, some of the config entries are arrays, which cannot be set using this command line tool

Example:

sdv-kanto-ctl set-value containers.insecure_registries registry:5000

leads to the incorrect configuration:

{
  "manager": {
    "default_ctrs_stop_timeout": 5
  },
  "log": {
    "log_file": "/var/log/container-management/container-management.log"
  },
  "things": {
    "enable": true
  },
  "deployment": {
    "init_dir": "${KANTO_MANIFESTS_DIR}"
  },
  "containers": {
    "insecure_registries": "registry:5000"
  }
}

Note that the correct configuration would be:

  ...
  "containers": {
    "insecure_registries": [
        "registry:5000"
     ]
  }

Suggest to add a new command to sdv-kanto-ctl to add entries into an array, e.g.

sdv-kanto-ctl add-entry containers.insecure_registries registry:5000

The jq command could look like this:

cat /etc/container-management/config.json | jq '.containers.insecure_registries |= [ "registry:5000" ]' > new-config.json

Users coming from k9s are used to specific keyboard shortcuts, such as d for describing a container or ctrl d for deleting a container etc. It would be nice if kantui would follow the same keyboard shortcuts convention, so that the transition is easier for users.

Ideas/Wishlist:

• ctrl-d for deleting a container
• ctrk-k for forced kill of a container
• ? to show a help dialog
• q and ctrl-c to quit kantui
• d to describe a container in more detail ("kanto-cm get ")
• v or enter to view a container (not sure what the difference is to describe, may less information? just the name, container image version etc.)
• e to edit a container (e.g. change name, change image ref, change environment variables) Editing existing containers is not yet implemented
• l to show the logs of a container

Todo:

• The basic commands for starting, stopping, restarting a container (prevent confusion of s for start and s for stop) should be refined
• Is there "pause" and "resume"?

I'm running kantui within a qemu environment, which runs inside of a Visual Studio Code terminal.
Usually, i am able to select text in the terminal and copy and paste it, for example for bug reports.

Unfortunately, the way how kantui renders the screen, i am unable to select any kind of text.

It would be great if I could have some way of copying text from the kantui, esp. the logs from a container. But it also includes the container id, container name or the whole list of containers.

Another team asked whether Leda would be able to import container archives from an USB stick, or whether container archives (and maybe deployment manifests) could be packaged as Conan packages for installation. I think it's two separate use cases, but i'm not quiet sure yet:

• Pre-installation of containerized applications using an existing automotive build toolchain. (e.g. by Conan packages).
• Offline-installation of containerized applications via an USB-Stick

As Leda team, we've been discussing whether kanto-auto-deployer would be the right place to implement/support these use cases. We consider KAD to be a convenience-tool for Leda quickstart image users, filling in the "gaps" in the SDV deployment concepts until they have been solved properly.

We have a tendency to say, let's support these use cases, but would like to get feedback from the community as well:

• KAD to monitor USB devices (or arbitrary dynamic mount points) for new container images (archives). This may bloat the scope of KAD, increase the binary size and makes it harder to maintain. It violates a bit the "one tool for one job" philosophy.
• Alternative to use a local container registry, acting as a proxy, so that container runtime or other tool like KAD doesn't need know about whether the container archives originate from. This is a level of indirection for the users and may be confusing at first.

Does anybody have such or similar use cases, please leave a comment!