Describe PoC goals and roles

[janhalen]

This issues purpose is to clarify and define the goals / scope / roles of the PoC.

Making the decision process transparent and open ensures all voices are heard, streamlining our path toward project goals while minimizing friction and inefficiency.

[janhalen]

Originally posted by @agnetemoos in #22

For a prototype, speed and evidence of real-world usability are crucial. A complete infrastructure project is not within the scope of a prototype.

An infrastructure setup will, of course, be needed if the prototype succeeds and receives further funding. But further funding is usually tied to the prototype providing evidence that it can produce the product it promises — namely a BorgerPC.

I am aware that Bluefin has too much software bundled in. I don't suggest using that as a base image

[janhalen]

**Originally posted by @0xf1e in #22

I have also tried to figure out the right "scope" for this PoC, and I think one way of deciding what should be in a prototype, i.e. which parts should be realistic, and which can be kept simple, the question is: Where do you currently see the most uncertainties and risks?

The goal of a PoC is usually to evaluate the highest-risk parts of a design. So what I would like to ask both of you, is: Which parts of the nornnet design make you think "I think this should work the way it is described here, but I'm not entirely sure either" (likelihood of failure)? And which parts make you think "If this part of the design doesn't work the way we expect it to, it's going to be really costly" (impact of failure)?

Every software project decisions that will inevitably fail. But with a PoC, we can ensure that we fail early, rather than late in the development process when changes will be costly.

In my opinion, any part of the system can be a fit for a PoC, as long as that is the part of the system where you see the highest risk (failure impact x failure likelihood).

[oyvindsk]

I this the right place to "think out loud" ?

I agree with @0xf1e : "the question is: Where do you currently see the most uncertainties and risks?"

In addition, maybe: What what would be a good demo? As in, how do we show off the promise in a good way? Some people might not immediately see the value in "immutable pull-based bootc update process built on GitOps" 😄 😆

I don't know what a good demo looks like. Maybe something around automatic provision and updates? Or just a better desktop than they have today? 🤷‍♂️

[oyvindsk]

(This got quite long, let me know if this is not the right place for this)

For the risk part, maybe we can come up with a few hypothesis (theories) that a PoC should help prove or disprove?

These can be broken up into Technical and Non-technical.

Just off the top of my head (needs more work, to say the least :)

Non-Technical:

• Users: This process will result in a system that works well for the users:
  • The "immutable" (atomic) part does not get in the way
  • The automatic updates are a plus
  • All the software (and printers etc) they need works well
  • etc etc
• Admins: This will make admins life easier:
  • Better fleet management (what does that mean?)
  • Better Security (what does that mean?)
  • Easier updates
  • Fewer problems
  • etc etc
• Non-functional:
  • This supports open source, digital sovereignty and avoids lock-in:
    • There are no lock-in to Github or other single vendors
  • The per-system costs will not be too high

See also #25

Technical:

These are just guesses, based on reading about bootc etc. It's hard to predict everything up-front, but it's still valuable to try 😄

I'm sure there will be many more questions (and lessons learned) when we start implementing this, and that's also valuable.

• bootc is mature enough
  • Building images is supported on the software the "admins" use
  • The provisioning and update process works well enough
  • There are no "blocking" / show-stopper bugs
• bootc and the whole "update process" is supported on the hardware they run
  • and also on the networks they use (firewalls? Proxies?)
• The deployed software is not too "esoteric" and works with the software the users need (Is Fedora okay? )
• Operating the needed infrastructure (if any) will be feasible in production
  • (for a PoC it should be easy enough : )
• etc etc

See also #22 and #23.

I'm sure @janhalen already knows the answer to some of these, having already tried bootc etc.

[agnetemoos]

Originally posted by @janhalen in #22

1. Minimizing Infrastructure Overhead: We are prioritizing a decentralized, "pull-based" model to reduce the number of moving parts. While PXE and management consoles like Foreman are established tools, they introduce significant external infrastructure dependencies. Our goal is to ensure the system is as resilient as possible by minimizing reliance on complex server-side environments.

2. GitOps as the Single Source of Truth: For our security and robustness model, we build on a GitOps workflow where the Git repository is the sole authoritative state of the fleet. By avoiding intermediate "admin consoles", statefull "device databases" and manual management practises, we proactively eliminate configuration drift—a core requirement for our project's stability.

3. Application and Config Delivery: We are leveraging modern patterns for modularity. Applications will be delivered either as part of the "core-apps" (e.g., LibreWolf) or as supplemental containerized apps via Logically Bound Images. This allows us to handle domain-specific or granular location-based configs (e.g., specific tags for self-service-pc or aarhus-municipal-library) entirely within the image structure, maintaining our "everything-is-an-image" philosophy.

4. Standardization over Custom DSLs: As mentioned previously, we are staying strictly within the OCI-native Containerfile DSL. This ensures our images remain fully portable and compatible with the broader cloud-native ecosystem without requiring specific CLI wrappers or emerging community-specific abstractions.

I would like to pull forward these bullet points made by @janhalen
I understand and agree to 1, 2 and 4.

But there are some aspects to 3 that I don't understand. I would really appriciate it if you @janhalen could elaborate on how Logically Bound Images will help me do tasks like setup a specific start page in the browser on computers at a specific location or install a network printer with a specific IP. I can see ansible-pull solve that job, but not Logically Bound Images.

Please don't hesitate to add some example code or technical explanation. If I came to understand, I would strengthen my faith in the NornNet project.

[agnetemoos]

I got it figured out now. I have made a prototype with a three layer setup.

• Base image = Fedora Silverblue
• Middle layer = Sikker selvbetjening
• Top layer = Sikker selvbetjening - local configurations.

Build is working and the local configs are available on the BorgerPC.
So far - so good.

But there are some aspects to 3 that I don't understand. I would really appriciate it if you @janhalen could elaborate on how Logically Bound Images will help me do tasks like setup a specific start page in the browser on computers at a specific location or install a network printer with a specific IP. I can see ansible-pull solve that job, but not Logically Bound Images.