Add architecture for INBM v5 #629
Conversation
There was a problem hiding this comment.
I would say the platform TPM is only accessed by a pre-exec shell script run by systemd before the inbm-daemon starts up.
| 1. #### inbm-daemon | ||
| - **Function**: Main manageability application which runs in the background | ||
| - **Main Tasks**: | ||
| - Spawns other `persistant` or `long-living` threads like `cloud-client`, `dispatcher-queue`, `telemetry-reporter` and `aggregator`. |
There was a problem hiding this comment.
not sure if this is necessary to mention at this level, but cloud client for example may spawn its own additional threads to deal with processing grpc or mqtt requests
| - **Function**: Management command queue | ||
| - **Main Tasks**: | ||
| - implements a simple queue of size `1` for device management commands | ||
| - invokes `updater` thread based on the type of update command e.g. firmware or os or application |
There was a problem hiding this comment.
also handles post-reboot tasks by launching 'updater' thread a second time if we have the appropriate entry in our metadata. also: we could keep a metadata file like platform update agent does, similar to our existing dispatcher_state
| 3. **Stage 3: Output**: | ||
| - Example: Execution of workloads, generation of results, or API responses. | ||
|
|
||
| Extensibility |
There was a problem hiding this comment.
First thought: with this architecture, modifying by third parties would require changes at source code level, so our focus there would be to provide clean interfaces to do so.
Things a third party might want to add:
- extra clouds
- extra telemetry
- new update types?
- new commands?
| Deployment | ||
| ---------- | ||
|
|
||
| [Content of Deployment] |
There was a problem hiding this comment.
Would be similar to existing Turtle Creek. Possibilities:
- Yocto recipe if desired
- .debs maybe with installer script
- Tiber packages
udm-bootstrap-- although perhaps this is something that belongs to UDM and doesn't need to be mentioned here
Would also mention installed vs. provisioned, and decommissioning.
|
|
||
| Security | ||
| -------- | ||
|
|
There was a problem hiding this comment.
Topics: unix domain socket, TPM, LUKS, AppArmor, filesystem privileges.
|
|
||
| Authentication | ||
| ~~~~~~~~~~~~~~ | ||
|
|
There was a problem hiding this comment.
authentication for this design is simple: clouds and inbc users have identity root or system administrator and can execute any valid command/manifest
|
|
||
| Scalability | ||
| ----------- | ||
|
|
There was a problem hiding this comment.
scalability is n/a as scope of INBM is single node; not much runs in parallel, small footprint
PULL DESCRIPTION
INBM v5 architecture
Impact Analysis
CODE MAINTAINABILITY
go fmtorformat-python.shas applicableCode must act as a teacher for future developers