Detail how we want the user experience to be

[mortenlj]

Jeg har prøvd å skrive en ADR basert på hva vi kom frem til i dagens møte. Jeg er usikker på om jeg husker enkelte detaljer riktig, og så er jeg usikker på om vi diskuterte alle detaljene. Tar gjerne tilbakemeldinger på om dette er en riktig fremstilling av hva vi ble enige om.

Spørsmål jeg er usikker på om vi diskuterte/usikker på om jeg husker riktig:

• Skal topic config også være en del av Application, eller skal brukerne opprette disse direkte? -Er det et problem at det er race condition mellom opprettelse av Secret og bruk av Secret?

[jhrv]

Ser veldig fint ut, og oppsummerer bra det som ble diskutert.

Det du nevner ang. race condition ved at naiserator setter secreten i PodSpec og vil vente på at kafkarator har opprettet den - er et pattern som er brukes bl.a. i nais/jwker og nais/azurerator og fungerer bra. Man utnytter her at Kubernetes her automatisk vil retrye og bli consistent, eventually ;) Tenker ikke at dette er en race condition nettopp pga det.

Kom også på at dette ble nevnt i går som et argument for at man har Kafka-konfigen integrert i Application. Det er såvidt jeg kan skjønne ikke riktig, og vil fungere like bra med egen CRD.

Det er ikke sikkert at det er best at alt angis i en Application. Tenker det avhenger av hvordan CRDen totalt sett vil se ut, og om dette er noe som vil gi mening for brukeren, samtidig som kafkarator får gjort det den skal. Til nå har de tilfellene vi har gjort dette hovedsaklig vært basert på to ting:

• en config er enklere å håndtere enn mange
• vi kan ofte tilby en enklere abstraksjon og skåne brukerene for mye yaml de ikke trenger forholde seg til. I dette tilfellet er det vi som definerer den bakenforliggende yamlen, så ikke sikkert at dette er et problem.

Det er sannsynligvis lettere å mene noe om dette når man kommer i gang med oppgaven og spec'en modnes litt.

[Kyrremann]

Hva betyr det å eie en topic? Er det slik at en som eiere en topic må godkjenne hvem som leser den?

[tronghn]

Det med tilgangskontroll som @Kyrremann nevner er noe man også må ta høyde for når man går for knytning mot Naiserator vs separat ressurs ala https://github.com/nais/alerterator.

GIr det mening å ha en sterk en-til-en-knytning mellom applikasjoner og topics? Enkelte team der ute deler gjerne en topic for mange av tjenestene sine, e.g. de som bruker https://github.com/navikt/rapids-and-rivers/. Ellers er det gjerne også topics som brukes på tvers av team. Samtidig blir det for meg uklart hvem som håndhever tilganger til topicer om det er "self-service"-innmelding via Application CRDen.

Patternet som er brukt for https://github.com/nais/jwker og https://github.com/nais/azurerator har tatt utgangspunkt i at ressursene som opprettes tilhører én og kun én applikasjon. Om man skal ta i bruk det samme her så tror jeg kanskje man burde skille mellom credentials som utstedes til individuelle apper og selve administrasjonen av Kafka topics i ulike ressurser.

[mortenlj]

Når det gjelder eierskap til et topic så har vi begynt å tenke at det er noe som er knyttet til et team, og ikke nødvendigvis til én applikasjon. Så der ser vi for oss en CRD (Topic) som beskriver topic konfigurasjonen og på et eller annet vis knytter den til et team. Det kan være first-come-first-serve, dvs. du får bare lov til å endre et Topic objekt hvis det er ditt team som står på den fra før eller noe sånt. Om denne deployes manuelt eller via en eller annen form for workflow/pipeline er litt åpent, men den trenger kanskje ikke deployes sammen med en Application? Kan man bruke nais/deploy/actions/deploy@master med en "vilkårlig" ressurs (uten en Application)?

Antageligvis så gir det mening at teamet som eier et topic håndhever tilgang, men her har vi snakket om at det også kan være på team nivå. Det må antageligvis gås opp litt ekstra med noen kompetente sikkerhetsmennesker 🙂. Hvis det er team, så kan det kanskje være en del av Topic objektet, med en liste over teams som kan produsere og en liste over teams som kan konsumere.

I andre enden så trenger en app å si hvilke topics den ønsker å produsere til eller konsumere fra, og hvis teamet som eier applikasjonen er på listen for topicet, så injectes passende credentials. Denne delen var det vi tenkte kunne legges til i Application, men den kan også være en egen CRD (AppTopics eller noe sånt?). Det er drodlet litt rundt disse tingene allerede i diverse issues på dette repoet, så ta gjerne en titt og kommenter der.

[Kyrremann]

Kan man bruke nais/deploy/actions/deploy@master med en "vilkårlig" ressurs (uten en Application)?

Ingen begrensning på nais/deploy på type ressurs.

Hvis det er team, så kan det kanskje være en del av Topic objektet, med en liste over teams som kan produsere og en liste over teams som kan konsumere.

Dette høres jo ut som en god idé, og siden teams har eget namespace, så kan man jo bare automagisk spytte inn secrets i riktig namespace. Og da kan app-ressurser bare bruke spec.envFrom for å laste inn secrets de trenger for å lese en topic.

---

Er det viktig at det er en bruker per app som leser? Da må man kanskje spesifisere team hos de som eier, og registrere apper i app-ressursen eller egen CRD, også sjekker den opp om du har lov basert på hvilke team som har lov.

[kgunnerud]

Litt om våres brukscase er:

• Noen få tilfeller har vi flere apps som produserer til samme topics.
• Vi har eksterne applikasjoner / teams som konsumerer fra våre topics, som vi som regel godkjenner. F.eks tilgang til alle dokumenter fra oss inneholder ekstremt mye info så da forventer vi typisk en PVK fordi man kan få mer enn man har hjemmel til.
• Fra tid til annen har vi endret fra compaction til ikke compaction

Per i dag har vi denne oversikten: https://github.com/navikt/pdl/blob/master/libs/utils-common/src/main/resources/common-kafka-topics.yaml

Likte forslagene som @mortenlj hadde rett over. Vi bryr oss egentlig ikke om hvilke apps andre teams bruker (og deres systembrukere), vi vil gi et team tilgang. Samtidig, vil vi gjerne at våres team kan være ansvarlig, ikke enkeltpersoner slik som nå fordi det er ganske sårbart når folk forsvinner. Men ser at kanskje det å slette topics kan potensielt være litt krise hvis det går litt raskt i svingene? Dette kan man kanskje løse ved rutiner i teamet.

[mortenlj]

Det er så fint at dere driver og approver denne, for tidligere i uka kom jeg frem til at det som står her ikke er helt hensiktsmessig/komplett lenger 😬.

I tillegg er det noen av kommentarene over som ikke helt er i samsvar med det som står i dokumentet, og hvor jeg er mer enig i kommentarene enn dokumentet, så jeg har begynt på å revidere det litt for å "rette" på et par ting og fylle ut med mer konkrete tanker her og der.

Så... oppdatering av PR kommer i løpet av uka, så kan vi se om vi fortsatt er enige 😄.

[mortenlj]

Jeg tror vi bare spikrer denne nå, så justerer vi etterhvert som vi kommer i gang med implementasjon og finner steder hvor det butter.