Operations guide to enable assesment of the Q12026 PoC #24
Labels
No labels
OpenGitOps
bootc
bug
documentation
duplicate
enhancement
epic
good first issue
help wanted
invalid
question
story
user-story
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
OS2/os2base#24
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
When #22 and #23 has reached "Done" state, a potential operator of the system should be able to perform a set of operations steps. These should be decided and refined, BUT as a minimum it should be described, how to "boot-strap" a bare metal device and an update of an image + verification of the following auto update.
This work should serve to identify gaps in knowledge and skills of operators and other stakeholders that need to operate this on a day to day basis.
This work will not strive to prove a 1:1 alignment or compatibility with previous systems, but serve as an anchor for showing the benefits and quality improvement of OpenGitOps.
I agree that these are essential for the assessment of the Q1 2026 POC:
Further assessment criteria could include some of the following tasks, which are frequently applied to BorgerPCs:
Yes, we definately need to define the final capabilites for the end-goal of the system in more detail. But lets work iteratively, instead of blocking Hackathon or PoC work until at "complete" definition has been agreed upon and verified.
To start a dialogue about this, I recommend we open a couple of User-story issues, that describes the value delivered by such technical tasks as described above. A user-story is an iterative process and a dialogue... so I recommend that we get started ASAP and that we invite more participants to discussing the story. @ChatBotBerg any inputs for how this could be done in an OS2 context?
I can help by creating a couple of stories that will encompass the above technical tasks... and add the first relevant question as a comment to get the discussion started. @agnetemoos: How do you like that way of working?
@agnetemoos: I have created this user-story issue to start the dialogue and highlight how this way of working with stories before technical tasks can deliver hideen value and avoid making the wrong dessicions at a specific time in a products life cycle.
Great idea. Lets do that.
I will produce a handful of user stories. I will ask the OS2BorgerPC koordinationsgruppe to contribute. Perhaps we can allocate time to work on them at our next meeting on February 2.
As a starting point of getting to grips with "how to operate" -
I will recommend this video 👇🏻
bootc: GitOps for Noobs
This video runs through the concepts and moving parts of a system based on the reference architecture I have recommended!
@dekov @agnetemoos @ChatBotBerg : you might be able to use this video-guide?