Thanks Alexander. It makes much more sense now. We believe that deploying applications in the car via containers is a good > idea for a couple of core reasons: I saw no references to containers on the SIG related pages. Is running containers in the car a stretch goal, or not in the scope of the SIG? I know it is very early on the project, but I am looking forward to seeing any demos :) Also, as a side effect, what would be exciting for me as a consumer is, using the smartphone analogy I saw around smart cars, the future where people mod their cars with custom software they buy on an app store. Like you flash ECUs for better HP these days, but with verified software on a button click :) On Tue, Mar 8, 2022 at 2:11 PM Alexander Larsson <alexl at redhat.com> wrote: > > > On Mon, Mar 7, 2022 at 11:52 PM Ali Ok <aliok at redhat.com> wrote: > >> Hi, >> >> I recently read a number of articles about how to offload workloads onto >> containers that run on vehicles. TheChief IO article here [0] summarizes >> some of the things tried out there and these are the experiments I've read >> in detail: >> >> - Mercedes-Benz did a POC [1] where they run containers in a vehicle to >> run relevant tasks. The focus here is on the development and CI/CD of these >> software. >> >> - Denso had a similar POC [2] [3]. They ran an entire Kubernetes cluster >> in the vehicle. Again, the focus here is the development ease and CI/CD. >> Development teams simply develop and distribute software just like a web >> application. There's also mentions of used concepts like digital twins, >> request queuing (in the vehicle when offline) and few other interesting >> concepts. >> >> How do these efforts align or relate with the automotive initiative? >> What I understand from CentOS automotive SIG and the POCs I mentioned >> above is that there are a lot of overlapping areas (being independent of >> the underlying hardware, faster software distribution, etc.) done in >> different levels (OS/Kube). >> > > Some of this aligns well with our current initiative, while the other > seems wildly unrealistic to me. > > We believe that deploying applications in the car via containers is a good > idea for a couple of core reasons: > > * More isolation between apps at runtime means more robust, safe, secure > software. > * Containerized applications can be updated and managed independently of > each other and the host os version. > * Containerization enforces a development model with strict interface > boundaries, similar to what you'd call a "microarchitecture" in the cloud > (although not necessarily using the exact same tech). This matches what the > expected development model is in the new "Software Defined Vehicle" world. > * The abstracted interfaces described above allow containers to run > outside of the actual car, using virtualized components for the rest of the > car. This is great for doing CI and development in the cloud and on a > developers local machine. > > Kubernetes is highly valuable in this model both for the CI/dev > environment and for running the cloud side of the services required for a > network-connected car. > > However, running kubernetes itself in the car itself is not a great idea. > The requirements that the code running in the vehicle is operating under > are very different from the cloud. For functionally safe code like this you > must know exactly ahead of time exactly what is running where and when, in > a predictable, repeatable fashion, ideally with a minimum of unnecessary > code running (as everything has to be validated in a very expensive > process). The dynamical nature of kubernetes just isn't a great fit, as > well as the high resource requirement and the fact that most of the > abstractions it provides wrt multi-node distribution and management just > isn't needed. > > Our plan is instead to run containers in the car more directly, managed > using systemd. > > -- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander Larsson Red Hat, Inc > alexl at redhat.com alexander.larsson at gmail.com > _______________________________________________ > CentOS-automotive-sig mailing list > CentOS-automotive-sig at centos.org > https://lists.centos.org/mailman/listinfo/centos-automotive-sig > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-automotive-sig/attachments/20220309/4b17262b/attachment-0002.html>