From 58da741bca8bb71a3637ec7e19696c9258dc66ac Mon Sep 17 00:00:00 2001 From: Stephan Lo Date: Wed, 4 Dec 2024 14:36:59 +0100 Subject: [PATCH 1/3] doc(architecture): added architectural decision of templated stacks --- .../design/proposal-stack-hydration.md | 28 +++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 content/en/docs/solution/design/proposal-stack-hydration.md diff --git a/content/en/docs/solution/design/proposal-stack-hydration.md b/content/en/docs/solution/design/proposal-stack-hydration.md new file mode 100644 index 0000000..adce110 --- /dev/null +++ b/content/en/docs/solution/design/proposal-stack-hydration.md @@ -0,0 +1,28 @@ +--- +title: Agnostic Stack Definition +weight: 2 +description: The implementation of EDF stacks must be kubernetes provider agnostic by a templating/hydration mechanism +--- + +* Type: Proposal +* Owner: Stephan Lo (stephan.lo@telekom.de) +* Reviewers: EDF Architects +* Status: Speculative, revision 0.1 + +## Background + +When booting and reconciling the 'final' stack exectuting orchestrator (here: ArgoCD) needs to get rendered (or hydrated) presentations of the manifests. + +It is not possible or unwanted that the orchestrator itself resolves dependencies or configuration values. + +## Proposal + +The hydration takes place for all target clouds/kubernetes providers. There is no 'default' or 'special' setup, like the Kind version. + +## Local development + +This implies that in a development process there needs to be a build step hydrating the ArgoCD manifests for the targeted cloud. + +## Reference + +Discussion from Robert and Stephan-Pierre in the context of stack development - there should be an easy way to have locally changed stacks propagated into the local running platform. \ No newline at end of file From 662d26581c6a6adffd2d9f693267b48736839812 Mon Sep 17 00:00:00 2001 From: Stephan Lo Date: Wed, 4 Dec 2024 14:48:53 +0100 Subject: [PATCH 2/3] feat(architecture): WiP ... just a notice on the outcome of today's arch session --- .../decision-iam-and-edf-self-containment.md | 31 +++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 content/en/docs/solution/design/decision-iam-and-edf-self-containment.md diff --git a/content/en/docs/solution/design/decision-iam-and-edf-self-containment.md b/content/en/docs/solution/design/decision-iam-and-edf-self-containment.md new file mode 100644 index 0000000..2ec75aa --- /dev/null +++ b/content/en/docs/solution/design/decision-iam-and-edf-self-containment.md @@ -0,0 +1,31 @@ +--- +title: eDF is self-contained and has an own IAM (WiP) +weight: 2 +description: tbd +--- + +* Type: Proposal +* Owner: Stephan Lo (stephan.lo@telekom.de) +* Reviewers: EDF Architects +* Status: Speculative, revision 0.1 + +## Background + +tbd + +## Proposal + +==== 1 ===== + +There is a core eDF which is self-contained and does not have any impelmented dependency to external platforms. +eDF depends on abstractions. +Each embdding into customer infrastructure works with adapters which implement the abstraction. + +==== 2 ===== + +eDF has an own IAM. This may either hold the principals and permissions itself when there is no other IAM or proxy and map them when integrated into external enterprise IAMs. + + +## Reference + +Arch call from 4.12.24, Florian, Stefan, Stephan-Pierre \ No newline at end of file From 7ab69e91395aea56a1acae1305e39ccd7cff8fab Mon Sep 17 00:00:00 2001 From: Stephan Lo Date: Wed, 11 Dec 2024 15:05:15 +0100 Subject: [PATCH 3/3] fix(): typo --- content/en/docs/concepts/2_engineering-people/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/2_engineering-people/_index.md b/content/en/docs/concepts/2_engineering-people/_index.md index 999dd9a..b333839 100644 --- a/content/en/docs/concepts/2_engineering-people/_index.md +++ b/content/en/docs/concepts/2_engineering-people/_index.md @@ -1,7 +1,7 @@ --- title: Engineers weight: 2 -description: 'Our clients: People creating code and bringing it to live - and their habits and contexts' +description: 'Our clients: People creating code and bringing it to life - and their habits and contexts' ---