Good Morning Everyone,
So here are some of the changes that we have worked on this week:
* We worked on some documentation about the different places you can contribute
packages in our ecosystem: Fedora, EPEL, the Automotive SIG and AutoSD, cf:
https://sigs.centos.org/automotive/contributing/building_packages/
* The general documentation about best practices for SIGs to use gitlab has been
merged: https://sigs.centos.org/guide/gitlab/
* We have added explicitly the linux-firmware-automotive package to content
resolver to replace the linux-firmware package with the aim to reduce the
image size by dropping the firmware that aren't relevant, cf:
https://github.com/minimization/content-resolver-input/pull/709
* We added some documentation on how you can use single-file offline ostree
updates:
https://sigs.centos.org/automotive/building/updating_ostree/#offline-delta-…
* The example rpms that were in the sample-image repostitory have been moved to
https://gitlab.com/CentOS/automotive/rpms, and the COPR repo where they used
to be built has been removed from the manifests.
* The manifests have changed to defaulting to static_uuids=true, where it was
false before. This means repeated builds of the same image will be more
reproducible, although the uuids will not be unique between builds.
* Some initial support for encrypting the root filesystem with LUKS was added.
Expect more work on this later though.
* We improved our documentation on customizing OSbuild templates:
https://sigs.centos.org/automotive/building/customize_template/
Happy hacking!
Pierre
Good Morning Everyone,
So here are some of the changes that we have worked on this week:
* You can now override the os version field in the ostree commit in the
images using the `ostree_os_version` variable.
* The runvm script now supports the `--watchdog` argument, which implements
an external watchdog that survives across VM resets.
* There is a new image that demonstrates how the watchdog can be used to
implement unattended OSTree updates. See
https://sigs.centos.org/automotive/building/unattended_updates/ for docs
about this.
* There were various fixes to the grub configuration to support the above.
Happy hacking!
Alex
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl(a)redhat.com alexander.larsson(a)gmail.com
Good Morning Everyone,
So here are some of the changes that we have worked on over the last couple
of weeks:
* We have worked on the osbuild templates and the repository structure to
make them more flexible and less cs9 specific.
This moves the configuration for the base cs9 stuff to a separate file
distro/cs9.ipp.yml, and allows you to easily create similar setups for
other distros (such as the AutoSD repos) which automatically creates the
right makefile targets for them. Etc.
* The work to enable a new lookaside cache structure is progressing: it has
been updated and we confirmed that we can upload to it, but CBS still needs
a little adjustment before it can use it (code is written, just needs to be
deployed)
* Started drafing the best-practices doc for using the centos namespace on
gitlab.com: https://git.centos.org/centos/sig-guide/pull-request/4
* We greatly improved our suppport for OSTree repository use.
The Makefile makes it easy to create and maintain a repo, and the runvm
changes makes it easy to allow VMs to access that repo. The new docs give
more context about what OSTree is and how it works. See
https://sigs.centos.org/automotive/building/updating_ostree/ for more
details!
* Some changes in the OSTree image type.
We now use bootloader=none, which means the grub config is not rewritten
on each update. There is now an ostree remote configured, and it is used as
the main origin for the ostree ref that was used, allowing for updates out
of the box. The url for the remote is configurable with a variable.
* The automotive SIG signed up for early access to gitlab.com/centos and
help the CentOS infra team to smooth the edges there
Happy hacking!
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl(a)redhat.com alexander.larsson(a)gmail.com
Good Morning Everyone,
So here are some of the changes that we have worked on over this week:
* We can now build from gitlab.com/redhat/automotive in CBS (cbs.centos.org),
note that we want to move to gitlab.com/centos/automotive as soon as the
authentication questions between gitlab and the CentOS account system are
solved.
* Repository structure for AutoSD has been simplified. It used to include the
CentOS repository from which the RPMs composing AutoSD had been pulled but
that was not necessary and ended up making AutoSD split across multiple
repositories instead of having just one. This is now fixed:
https://autosd.sig.centos.org/AutoSD-9/latest/cs9/
(as I write this email I realize that we still have some redundancy in the
path here...)
* Remote-build has been improved to make it easier to run, now all you need is
to write your configuration file and ensure you have podman installed on the
targeted hosts! The client handles the rest. Sources:
https://github.com/pypingou/remote_builder
* Increased the size of the `/boot` partition on our sample images to 300M so it
has enough space to install up to 3 kernels.
* The rpm repository moved from the folder `product-builds` to `AutoSD-9` at:
https://autosd.sig.centos.org/
Happy hacking!
Pierre
Good Morning Everyone,
So here are some of the changes that we have worked on over the last couple of
weeks:
* We got a sub-domain for AutoSD, so you can browse it at:
https://autosd.sig.centos.org/
* We kept on working on allowing a new lookaside cache structure on CentOS'
infrastructure, giving SIGs more flexibility on their workflow (cf the
discussion on the centos-devel list)
* We worked on some sample containers interacting via SOME/IP, cf:
https://lists.centos.org/pipermail/centos-automotive-sig/2022-March/000085.…
* We have a new tool called runvm in the repo which makes it easier to run
images with qemu
* Our manifest now have a variable you can use if you want to add extra
repositories (in addition to extra packages) when building images. It will go
something like:
`make cs9-qemu-minimal-regular.aarch64.qcow2 DEFINES='extra_repos=[{"id":"foo","baseurl":"http://foo"}] extra_rpms=["some","rpms"]'`
(documentation will be updated shortly)
Happy hacking!
Pierre
Hi all - you can find past CentOS Automotive SIG meeting recordings, as
well as information on upcoming meetings and events, on this page:
https://wiki.centos.org/SpecialInterestGroup/Automotive/Meetings
Thanks to everyone who made it to today's office hours, where we discussed
the current technical status as well as future options for hardware and
board support. In particular, there was an active discussion around the
best ways to accommodate custom kernels and long term support - thanks to
Fulup and Stephane for a very interesting topic.
I have started a wiki page specifically to discuss & track hardware ideas
here:
https://wiki.centos.org/SpecialInterestGroup/Automotive/Hardware
So please feel free to log in and contribute, both here and elsewhere in
the wiki.
Thanks & see you all for the next meeting on April 8
Jeffrey "Jefro" Osier-Mixon | jefro(a)redhat.com
Red Hat Office of the CTO | Sr. Principal Community Architect, Automotive
I talked earlier here about the work I was doing to improve the container
sample image in the automotive sig repo. Well, today I landed the initial
version of this in gitlab.
Check out the docs here:
https://sigs.centos.org/automotive/building/containers/
and:
https://gitlab.com/redhat/automotive/automotive-sig/-/blob/main/sample-apps…
Basically it create some "automotive-like" apps that use SOME/IP to talk to
each other, then embed these apps into containers and run then as system
services under systemd which are automatically started at boot. There is
even some custom selinux policies to manage the vsomeip socket file access.
Check it out and play with it.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl(a)redhat.com alexander.larsson(a)gmail.com
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).
Context: I am a Knative (https://knative.dev) contributor at Red Hat. I was
thinking about experimenting with Knative Eventing on the far edge, or even
better, mentor a Google Summer of Code contributor this summer for that,
and later I found out about the experiments done with Kubernetes on
vehicles.
[0]
https://thechief.io/c/editorial/how-kubernetes-is-shaping-the-future-of-car…
[1]
https://customers.microsoft.com/en-us/story/784791-mercedes-benz-r-and-d-cr…
[2] https://kubernetes.io/case-studies/denso/
[3]
https://www.denso.com/jp/ja/-/media/global/business/innovation/review/25/pa…