Hey Ali! Thanks for the great insight here, it's something I have thought about myself a number of times. See more inline! Leigh On Wed, Mar 9, 2022 at 2:34 PM Ali Ok <aliok at redhat.com> wrote: > 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? > If you check out https://wiki.centos.org/SpecialInterestGroup/Automotive you can read the charter which states the SIG *is meant to be a neutral public space for collaboration between third parties interested in open development of software targeted at in-vehicle automotive use cases. * To that end, containers running within a car is something that would be a welcome discussion and contribution and I'd love to get experts like you and others engaged! > > 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 >> > _______________________________________________ > CentOS-automotive-sig mailing list > CentOS-automotive-sig at centos.org > https://lists.centos.org/mailman/listinfo/centos-automotive-sig > -- Leigh Griffin Senior Manager, Emerging OS Platforms Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgriffin at redhat.com M: +353877545162 IM: lgriffin @redhatjobs <https://twitter.com/redhatjobs> redhatjobs <https://www.facebook.com/redhatjobs> @redhatjobs <https://instagram.com/redhatjobs> <https://red.ht/sig> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-automotive-sig/attachments/20220309/14885913/attachment-0002.html>