feat: account hierarchy #10
Open
Conversation
This file contains hidden or 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
nexus49
reviewed
Jul 19, 2024
Member
nexus49
left a comment
nexus49
left a comment
There was a problem hiding this comment.
I think in the context you could elaborate briefly on what an account is and what purpose it has. I think you should also briefly explain the concept of "extensions" and what they do on a high level.
| @@ -0,0 +1,37 @@ | |||
| # RFC for openMFP Account Hierarchy | |||
Member
There was a problem hiding this comment.
Suggested change
| # RFC for openMFP Account Hierarchy | |
| # RFC for OpenMFP Account Hierarchy |
|
|
||
| ## Context and Problem Statement | ||
|
|
||
| This document provides an outline of how and what should be achieved with an account hierarchy model within openMFP. An account will have the ability to benefit from other accounts that it is a child of, e.g., by inheriting extensions provided by its parents. This will allow for easier distribution of central extensions and give more structure to the entire account setup. |
Member
There was a problem hiding this comment.
Suggested change
| This document provides an outline of how and what should be achieved with an account hierarchy model within openMFP. An account will have the ability to benefit from other accounts that it is a child of, e.g., by inheriting extensions provided by its parents. This will allow for easier distribution of central extensions and give more structure to the entire account setup. | |
| This document provides an outline of how and what should be achieved with an account hierarchy model within OpenMFP. An account will have the ability to benefit from other accounts that it is a child of, e.g., by inheriting extensions provided by its parents. This will allow for easier distribution of central extensions and give more structure to the entire account setup. |
| - Accounts within the same hierarchy must be able to inherit extensions from their parents until the root is reached. | ||
| - There is (theoretically) no limit on the depth of the hierarchy. | ||
| - There will be a root account (root of the hierarchy tree) that provides the necessary foundation for all other accounts. | ||
| - "First-Level Accounts" have a special role and act as a top-level separator for configurations. |
Member
There was a problem hiding this comment.
In what way are first level accounts special? If they are we should elaborate on this more
| - There will be a root account (root of the hierarchy tree) that provides the necessary foundation for all other accounts. | ||
| - "First-Level Accounts" have a special role and act as a top-level separator for configurations. | ||
|
|
||
| ## Options Considered |
Member
There was a problem hiding this comment.
In an RFC - given that you only outline one Option, I'd skip this part as its not a ADR. Rather outline the proposal
|
|
||
|  | ||
|
|
||
| The above diagram visualizes how such a tree could look. Every account currently generates a namespace. When another account resource is being placed within that namespace, the new account will be considered a child of the account that generated the namespace. |
Member
There was a problem hiding this comment.
Suggested change
| The above diagram visualizes how such a tree could look. Every account currently generates a namespace. When another account resource is being placed within that namespace, the new account will be considered a child of the account that generated the namespace. | |
| The above diagram visualizes how such a tree could look. Every account generates a namespace. When another account resource is being placed within that namespace, the new account will be considered a child of the account that generated the namespace. |
| - **Pros:** | ||
| - Easy way of central distribution of extensions to all accounts in the system. | ||
| - **Cons:** | ||
| - It might be intransparent and a bit of effort to figure out the hierarchy chain up to the root account and therefore get a list of all the extensions. No newline at end of file |
Member
There was a problem hiding this comment.
Well its only an effort if you consider kubectl looking at namespaces, it'd be rather easy to have a kubectl plugin for example that shows and visualizes the hierarchy
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.
First draft of a RFC that describes a possible account-hierarchy implemention within openMFP