Q&A - SUSE presentation

[ghost]

OpenAD-KIT-SUSE-Feb-2022.pdf
SUSE follow-up Q&A.xlsx

SUSE gave a presentation on how their products could potentially be used with the Open AD Kit during the Open AD Kit meeting on February 24th. Some initial questions were handled at the time and then some follow-up questions from TIER IV were discussed in the next meeting on March 10th.

This discussion has been set up to enable async discussion with the SUSE team for any new or existing questions (the spreadsheet of questions posed by TIER IV has been attached above).

[kei-t4]

Currently, Open AD Kit WG has its software stack. The most of it is developed by SOAFEE, then the reference implementation is named EWAOL.
So SUSE's initial plan is to have k3s integrated in EWAOL.
Is my understanding correct?

This question is a subsequent of No 10 in SUSE follow-up Q&A.xlsx

[afaerber]

My assumption is that K3s is already integrated into Yocto based EWAOL. @mak3r would have more details on that (compare question 6).

It is also possible to use K3s on other Linux distros of your choice. SOAFEE's policy is to contribute to upstream projects, so it'll be a matter of which version you use and not of where you get it from.

[kei-t4]

I see, thanks!
My concern was that Open AD Kit would have another software stack variants, so k3s already included into EWAOL sounds good.

[ghost]

@mak3r @shpwrck Hi guys, I just wanted to follow up about question 9 on the spreadsheet above (I think some kind of visual was needed to answer this?), as well as the additional question from @kei-t4 above. Cheers!

[afaerber]

Regarding question 9:

The attached image (see picture 1 on the right) is an example of an ADK hardware/software block diagram, both Edge and Cloud-side. It would be appreciated if you could indicate any parts that can be achieved using solutions from SUSE. I would like to understand what is in scope and out of scope for SUSE. Also it would be very helpful if you could describe the benefit we would have by implementing SUSE's solutions.

I spot in the diagram:

• AWS G5g cloud instance with NVIDIA T4G GPU:
  • SUSE Linux Enterprise Server on Arm 15 SP3 runs on AWS Graviton2; theoretically also SUSE Linux Enterprise High Performance Computing 15 SP3 and SLE Micro 5.1, but possibly not yet conveniently on the AWS Marketplace.
  • NVIDIA offers GPU drivers and CUDA stack for SUSE customers as an opt-in SLE Module.
  • SUSE Manager target support is available for updating etc.
• ADLINK AVA AP1 with NVIDIA RTX5000 GPU:
  • SUSE Linux Enterprise Server on Arm 15 SP3 and SLE Micro 5.1 run on Ampere Altra and are being tested on AVA Developer Platform; for Automotive QM Linux variants or safety certifications talk to @joesusecom and/or SUSE Embedded Sales.
  • NVIDIA CUDA module for SLE
  • SUSE Manager target support for SLE
  • Out of scope would be the NXP S32S micro-controller and Zephyr RTOS.
• Container runtime (not depicted):
  • K3s is a light-weight Kubernetes container orchestrator for Edge systems and can run on top of SLE, Ubuntu and presumably Amazon Linux (@mak3r? @shpwrck?), as well as EWAOL and other third-party Linux distros.
    • Currently out of scope would be deployment of Zephyr/RTOS firmware updates (non-containers) via any Kubernetes orchestrator, whether K3s or otherwise.
      If Linux/RTOS interactions are relevant to Tier IV, as member they can propose such use cases to SOAFEE (preliminarily via Cloud Native Dev working group and Google Docs, in the future via Jira tickets and System Architecture working group).
  • SUSE Rancher 2.6 management solutions work across RKE(2), K3s, Amazon EKS and further third-party Kubernetes runtimes (compare slide 6).
• Container images (A, B):
  • SUSE Linux Enterprise Base Container Images can be pulled from https://registry.suse.com/ as base image for containerized applications.
    • Currently out of scope are Autoware, ROS2 and Cyclone DDS.
      • Could be packaged and made available by third-parties via SUSE Package Hub (slide 5).
        • During a SUSE Hackweek a few years back I personally started some ROS and ROS2 packaging for openSUSE:
          https://build.opensuse.org/project/show/home:a_faerber:ros:ros2
          https://build.opensuse.org/project/show/home:a_faerber:ros
      • Third-parties could host their own BCI-derived container images themselves (instead of or in addition to making packages available).
  • ( Open Build Service client&server or Geckito pbuild tool ) and/or Kiwi tool can be used to build container images.
  • Fleet can be used to deploy containers (bundles) via GitOps.
  • NeuVector (recently acquired and open-sourced by SUSE) can be used to scan container images; application-level firewall functionality at runtime may still require adaptation for K3s.

Further potentially applicable components are shown on slides 6-11.

Now, not sure what you mean with "implementing SUSE's solutions"? I'm guessing you meant adopting Kubernetes over Docker?

Christophe had pointed out on slide 10 that you'd need to author a (Helm) Deployment Chart for your containers. Instead of running four containers interactively in terminal windows using Docker for each (https://gitlab.com/autowarefoundation/autoware_reference_design/-/blob/main/docs/Appendix/Open-AD-Kit-Start-Guide/run-autoware.md / https://github.com/autowarefoundation/autoware-documentation/blob/main/docs/installation/autoware/docker-installation.md), you can then deploy the whole pod with multiple containers at once to a cluster (with potentially multiple nodes) using a single Kubernetes command. Kubernetes as container orchestrator may even be able to use dockerd as container runtime backend, so should rather be considered a more powerful alternative to Docker Swarm. Essentially, Kubernetes uses YAML text files (e.g., kubectl apply -f foo.yaml), and Helm adds some more magic around that IIUC. Once you have your config ready, you should be able to deploy on virtually any Kubernetes cluster - no special implementation for SUSE needed.

SOAFEE members will be looking into implementing additional features for K3s, Container Network Interfaces (abstraction of inter-container networking across cluster nodes) and other container runtime components as needed for mixed-critical workloads. For example, allowing individual containers in a pod to specify that they want the runtime to execute them with real-time process priority (for PREEMPT_RT scheduler). Or how to best deal with time-critical Ethernet TSN or CAN network traffic into and out of containers. Deployment Charts making use of such new features may then need to require newer versions of Kubernetes to ensure config settings get applied as expected.

Hope that helps.