Design

• 1: Agnostic EDF Deployment
• 2: Agnostic Stack Definition
• 3: eDF is self-contained and has an own IAM (WiP)
• 4:
• 5:
• 6:
• 7:

1 - Agnostic EDF Deployment

• Type: Proposal
• Owner: Stephan Lo (stephan.lo@telekom.de)
• Reviewers: EDF Architects
• Status: Speculative, revision 0.1

Background

EDF is running as a controlplane - or let’s say an orchestration plane, correct wording is still to be defined - in a kubernetes cluster. Right now we have at least ArgoCD as controller of manifests which we provide as CNOE stacks of packages and standalone packages.

Proposal

The implementation of EDF must be kubernetes provider agnostic. Thus each provider specific deployment dependency must be factored out into provider specific definitions or deployment procedures.

Local deployment

This implies that EDF must always be deployable into a local cluster, whereby by ’local’ we mean a cluster which is under the full control of the platform engineer, e.g. a kind cluster on their laptop.

2 - Agnostic Stack Definition

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

3 - eDF is self-contained and has an own IAM (WiP)

• 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

4 -

why we have architectural documentation

TN: Robert, Patrick, Stefan, Stephan 25.2.25, 13-14h

referring Tickets / Links

• https://jira.telekom-mms.com/browse/IPCEICIS-2424
• https://jira.telekom-mms.com/browse/IPCEICIS-478
• Confluence: https://confluence.telekom-mms.com/display/IPCEICIS/Architecture

charts

we need charts, because:

• external stakeholders (especially architects) want to understand our product and component structure(*)
• our team needs visualization in technical discussions(**)
• we need to have discussions during creating the documentation

(*): marker: “jetzt hab’ ich das erste mal so halbwegs verstanden was ihr da überhaupt macht” (**) marker: ????

typed of charts

• schichtenmodell (frontend, middleware, backend)
• bebauungsplan mit abhängigkeiten, domänen
• kontext von außen
• komponentendiagramm,

decisions

• openbao is backend-system, wird über apis erreicht

further topics / new requirements

• runbook (compare to openbao discussions)
• persistenz der EDP konfiguartion (zb postgres)
• OIDC vs. SSI

5 -

arbeitsteilung arcihtekur, nach innen und nach aussen

Sebastiano, Stefan, Robert, Patrick, Stephan 25.2.25, 14-15h

links

• https://confluence.telekom-mms.com/display/IPCEICIS/Team+Members

montags-call

• Sebasriano im montags-call, inklusive florian, mindestens interim, solange wir keinen architektur-aussenminister haben

workshops

• nach abstimmung mit hasan zu platform workshops
• weitere beteiligung in weiteren workshop-serien to be defined

programm-alignment

• sponsoren finden
• erledigt sich durch die workshop-serien

interne architekten

• robert und patrick steigen ein
• themen-teilung

produkt struktur

edp standalone ipcei edp

architektur themen

stl

produktstruktur application model (cnoe, oam, score, xrd, …) api backstage (usage scenarios) pipelining ’everything as code’, deklaratives deployment, crossplane (bzw. orchestrator)

ggf: identity mgmt

nicht: security monitoring kubernetes internals

robert

pipelining kubernetes-inetrnals api crossplane platforming - erzeugen von ressourcen in ‘clouds’ (e.g. gcp, und hetzner :-) )

patrick

security identity-mgmt (SSI) EaC und alles andere macht mir auch total spass!

einschätzungen

• ipceicis-pltaform ist wichtigstes teilprojekt (hasan + patrick)
• offener punkt: workload-steuerung, application model (kompatibility mit EDP)
• thema security, siehe ssi vs. oidc
• wir brauchen eigene workshops zum definieren der zusammenarbiets-modi

committements

• patrick und robert nehmen teil an architektur

offen

• sebastian schwaar onboarding? (>=50%) — robert fragt
  • alternative: consulting/support anfallsweise
  • hält eine kubernetes einführungs-schulung –> termine sind zu vereinbaren (liegt bei sophie)

6 -

crossplane dawn?

• Monday, March 31, 2025

Issue

Robert worked on the kindserver reconciling.

He got aware that crossplane is able to delete clusters when drift is detected. This mustnt happen for sure in productive clusters.

Even worse, if crossplane did delete the cluster and then set it up again correctly, argocd would be out of sync and had no idea by default how to relate the old and new cluster.

Decisions

1. quick solution: crosspllane doesn’t delete clusters.
   • If it detects drift with a kind cluster, it shall create an alert (like email) but not act in any way
2. analyze how crossplane orchestration logic calls ‘business logic’ to decide what to do.
   • In this logic we could decide whether to delete resources like clusters and if so then how. Secondly an ‘orchestration’ or let’s workflow how to correctly set the old state with respect to argocd could be implemented there.
3. keep terraform in mind
   • we probably will need it in adapters anyway
   • if the crossplane design does not fir, or the benefit is too small, or we definetly ahve more ressources in developing terraform, the we could completley switch
4. focus on EDP domain and application logic
   • for the momen (in MVP1) we need to focus on EDP higher level functionality

7 -

platform-team austausch

stefan

• initiale fragen:
• vor 2 wochen workshop tapeten-termin
• wer nimmt an den workshops teil?
• was bietet platform an?
• EDP: könnte 5mio/a kosten
  • -> produkt pitch mit marko
  • -> edp ist unabhängig von ipceicis cloud continuum*
  • generalisierte quality of services ( <-> platform schnittstelle)

Hasan

• martin macht: agent based iac generation
• platform-workshops mitgestalten
• mms-fokus
• connectivity enabled cloud offering, e2e von infrastruktur bis endgerät
• sdk für latenzarme systeme, beraten und integrieren
  • monitoring in EDP?
• beispiel ‘unity’
• vorstellung im arch call
• wie können unterschieldiche applikationsebenen auf unterschiedliche infrastruktur(compute ebenen) verteit werden
• zero touch application deployment model
• ich werde gerade ‘abgebremst’
• workshop beteiligung, TPM application model

martin

* edgeXR erlaubt keine persistenz
    * openai, llm als abstarktion nicht vorhanden
    * momentan nur compute vorhanden
    * roaming von applikationen --> EDP muss das unterstützen
    * anwendungsfall: sprachmodell übersetzt design-artifakte in architektur, dann wird provisionierung ermöglicht

? Applikations-modelle ? zusammenhang mit golden paths * zB für reines compute faas