Add RFC-0002 (Layer Architecture) #20
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
twelho
added
do-not-merge/wip
luxas
approved these changes
Jun 24, 2021
docs/rfcs/0002-layer-architecture.md
Outdated
|
|
||
| _One paragraph explanation of the feature._ | ||
|
|
||
| This RFC describes the overall Racklet architecture, its defining layers, and requirements for each such layer, derived from [RFC-0001]. For each layer the defining components are described at a high level (avoiding implementation details). The compnoents are associated with their role and five highlighted key requirements from the values and user goals of [RFC-0001]. |
docs/rfcs/0002-layer-architecture.md
Outdated
|
|
||
| - Define well-known layers of Racklet. | ||
| - Describe the requirements for each layer. | ||
| - Describe roughly how to be "Racklet conformant" and what the differences are between Racklet and other similar alternatives. |
There was a problem hiding this comment.
If we're not answering this now, we can just omit this. I don't think we need to solve this problem in full now anyways.
There was a problem hiding this comment.
RFC-0002 is intended to partially assess that topic, but I'll see if I can reword that to sound less like this document is going to give an in-depth answer.
docs/rfcs/0002-layer-architecture.md
Outdated
|
|
||
| _The section should return to the examples given in the guide-level explanation below, and explain more fully how the detailed proposal makes those examples work._ | ||
|
|
||
| Racklet is divided into 5 distinct layers, from lowest-level to highest-level: |
There was a problem hiding this comment.
reverse this so it's in line with how the RFC is read?
There was a problem hiding this comment.
Yep, Markdown was being a bit difficult with reversed lists, but I managed to find a workaround.
docs/rfcs/0002-layer-architecture.md
Outdated
|
|
||
| | Component | Role | Key Requirements | | ||
| | -------------------------------- | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------- | | ||
| | **VM image building automation** | Define and run VMs declaratively | [Improve status quo], [Openness], [Declarative management], [Documentation], [Fast reconfiguration] | |
There was a problem hiding this comment.
s/VM image building automation/Micro-Virtual Machine orchestration/
docs/rfcs/0002-layer-architecture.md
Outdated
| | Component | Role | Key Requirements | | ||
| | -------------------------------- | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------- | | ||
| | **VM image building automation** | Define and run VMs declaratively | [Improve status quo], [Openness], [Declarative management], [Documentation], [Fast reconfiguration] | | ||
| | **Kubernetes VM image** | Consume/use a Kubernetes cluster | [De-facto standards], [Declarative management], [Loose coupling], [Upgradability], [Utilize Kubernetes] | |
There was a problem hiding this comment.
I'd omit "VM image" here as an implementation detail, and describe it instead as a system of components, which it is gonna be at the end of the day, so e.g. Kubernetes deployment automation
docs/rfcs/0002-layer-architecture.md
Outdated
| - If applicable, provide sample error messages, deprecation warnings, or migration guidance. | ||
| - If applicable, describe the differences between teaching this to a Racklet administrator versus a Racklet end user. | ||
|
|
||
| **TODO**: Mention what is the difference between "reference" implementation and "community" implementations. TBD |
docs/rfcs/0002-layer-architecture.md
Outdated
|
|
||
| Explain the proposal as if it was already a feature of the project and this would be the documentation for that feature. | ||
|
|
||
| - Introducing new named concepts. |
There was a problem hiding this comment.
BMC and RMC would be two examples.
There was a problem hiding this comment.
This section needs a bit of a rewrite.
docs/rfcs/0002-layer-architecture.md
Outdated
|
|
||
| As stated in [Risks and Mitigations](#risks-and-mitigations), Racklet is (one of) the first of its kind with regards to its specification-first architecture. The initial layer separation presented here is the result of an iterative thought process by the core Racklet authors. The five layers are chosen to clearly separate roles and responsibilities of components, without going into too much detail (too many layers) or causing excessive overlap (too few layers). Firmware and system software are separated to achieve loose coupling and clear, secure communication between them. User software is separated from system software to define a border between software mostly provided by the Racklet project and external software that the user introduces (workloads). | ||
|
|
||
| [Loose coupling] plays a very important role in the architecture presented here. Racklet could have been designed as a fully integrated system with implementations that are strictly defined by the project, but while this potentially could make the system more compact and simple, it also faces many drawbacks that make it incompatible with the values and goals of the project. For example, Racklet relies heavily on various different projects in the Open Firmware and Cloud Native ecosystems, many of which evolve quickly and provide alternative implementations complying to standard APIs. We want Racklet to be accessible, transparent and modular, which means supporting a wide variety of hardware, and enabling user customization to a great extent. If loose coupling is implemented properly, we believe that the standardized architecture presented here will be relatively simple to maintain and extend, and community-built Racklet solutions will also be able to use the modules and different software implementations effortlessly. In summary, to fulfill the values defined in [RFC-0001] and to avoid ecosystem fragmentation the Racklet project aims to provide interfaces, not implementations. |
docs/rfcs/0002-layer-architecture.md
Outdated
|
|
||
| TODO: Explain what is the difference between this try and prior RPi clusters. | ||
|
|
||
| At the time of Racklet creation the history of Raspberry Pi (and other SBC) based cluster computers is already very rich. Various private persons, educational insistutes and companies have come up with a wide variety of designs (**TODO: Examples**) for different use cases for at least the past 10 years. What sets Racklet apart from these mostly one-off implementations is it's **specification**. Instead of deriving a specification from some implementation, Racklet as a system is *primarily* defined as a set of RFC documents. This specification is intended to define a **standardized** way to build a miniature compute cluster, from the lowest-level hardware details up to a state-of-the-art software stack. Since the specification is defined from the ground up, we prioritize basing it on the most _secure_ and _modern_ technologies available today, essentially merging the core concepts of prior SBC cluster computer implementations with the state of the art security and fleet management models of large-scale cloud providers. |
There was a problem hiding this comment.
Examples: https://github.com/kubecloud/thesis
docs/rfcs/0002-layer-architecture.md
Outdated
|
|
||
| ## Motivation | ||
|
|
||
| _Why are we doing this? What use cases does it support? What is the expected outcome?_ |
There was a problem hiding this comment.
let's remove these now. They make the document a bit hard to review.
twelho
force-pushed
the
rfc/layer-architecture
branch
from
a4bfb03
to
246c907
Compare
|
I've now overhauled the guide-level explanation and done a bunch of improvements all around. Perhaps a bit embarrassingly, the core of Racklet, the compute unit, was missing in the layer description altogether, so that's now been added as well. |
luxas
approved these changes
Jul 20, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This RFC shall describe the requirements of the individual layers of Racklet in more detail. It doesn't describe the implementation details of each layer, those will be covered by upcoming RFCs.
Closes #21.