Learn more about these different git repos.
Other Git URLs
For the 2018 IOT/Atomic GSOC idea we have @lorbus who is the student doing most of the work. We also have @pbrobinson @jlebon and myself helping to coordinate and mentor.
We met last week to go over the high level design of the project. We scratched notes on an etherpad (I'll persist those notes in a text file in this issue as well).
Some high level things that came out of the discussion:
This needs to be generic enough to allow OS admins to bring your own boot health check. It needs to either be a daemon or possibly re-use systemd and systemd units to achieve the same goal. We should also provide some sane default boot health checks. rpm-ostree needs some way to interface and discover failed boot health checks.
Lots of possibilities discussed here. We can use hardware watchdog features and possibly set "boot once" in GRUB/UEFI features to achieve this goal.
If a system failed to boot let's not blindly re-apply the failed update and try again (infinite looping on failure). Showing boot health checks in status output is a +.
We'll break each of these out into subtickets and continue on with specific discussion in each of those.
Added backup etherpad text file:
<img alt="etherpad.txt" src="/fedora-iot/issue/raw/files/9cf4a3744cace1d678afda2affd2c2d3f5792436249eecea2f0d648a07f7fcf7-etherpad.txt" />
Metadata Update from @pbrobinson: - Issue tagged with: GSoC
had our second discussion today: here is what came of it: https://pagure.io/fedora-iot/issue/2#comment-511940
had our third discussion today: action items currently:
@dustymabe:
@lorbus :
@jlebon:
@pbrobinson:
OK, played around with greenboot for a bit. (I really like the name BTW!)
I think I understand why you went with a service instead of a target -- though OTOH, I really like the semantics of targets for our use case. systemd has these nice well-known targets which serve as interfaces for other services to hook into. One I recently came across was: the nss-user-lookup.target can be used to separate services that provide NSS lookup services (like SSSD) from those that require it (like systemd-logind). Similarly, a greenboot.target can be the interface other units plug into. (E.g. both for running things before the target, like the various tests, but also after, e.g. telling the mothership we're ready).
nss-user-lookup.target
systemd-logind
greenboot.target
Here's a strawman:
WantedBy
multi-user.target
RequiredBy
greenboot.service
After=greenboot.target
@jlebon: Thanks for the feedback! I'm seeing the usecase for targets now more and more, too and had a similar idea of what to use greenboot.target for (see my comment in issue #3)
I'll incorporate this in the next iteration of greenboot!
migrated your comments to https://pagure.io/fedora-iot/issue/2 - let's keep the discussion over there :)
Should we have another meeting to wrap things up? I think @pbrobinson said he wasn't available this Friday, so maybe next week?
Metadata Update from @pbrobinson: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.