Patrick.Sy/website-and-documentation
1
0
Fork 0
forked from DevFW-CICD/website-and-documentation
Code Pull requests Activity

Merge branch 'development'

Browse source
This commit is contained in:
Stephan Lo 2024-12-19 10:04:45 +01:00
commit 311269eb39
3 changed files with 60 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

2
content/en/docs/concepts/2_engineering-people/_index.md
View file

@ -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'
---

31
content/en/docs/solution/design/decision-iam-and-edf-self-containment.md Normal file
View file

@ -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

28
content/en/docs/solution/design/proposal-stack-hydration.md Normal file
View file

@ -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.