Skip to content

Conversation

olamilekan000
Copy link
Contributor

Summary

change adds mermaid diagram to kcp terminologies inorder to 
help further explain what each does.

What Type of PR Is This?

/kind documentation

Related Issue(s)

Fixes #

Release Notes

NONE

@kcp-ci-bot kcp-ci-bot added release-note-none Denotes a PR that doesn't merit a release note. kind/documentation Categorizes issue or PR as related to documentation. dco-signoff: yes Indicates the PR's author has signed the DCO. labels Sep 28, 2025
@kcp-ci-bot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign mjudeikis for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@kcp-ci-bot kcp-ci-bot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Sep 28, 2025
@kcp-ci-bot
Copy link
Contributor

Hi @olamilekan000. Thanks for your PR.

I'm waiting for a kcp-dev member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@kcp-ci-bot kcp-ci-bot added the needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. label Sep 28, 2025
@olamilekan000 olamilekan000 force-pushed the add-contextual-diagram-to-terminologies branch 2 times, most recently from 713016a to 6a76879 Compare September 28, 2025 21:16
@mjudeikis mjudeikis requested review from embik and xrstf September 29, 2025 06:00
@mjudeikis
Copy link
Contributor

/ok-to-test

@kcp-ci-bot kcp-ci-bot added ok-to-test Indicates a non-member PR verified by an org member that is safe to test. and removed needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Sep 29, 2025
@olamilekan000 olamilekan000 force-pushed the add-contextual-diagram-to-terminologies branch from 6a76879 to 06194b8 Compare September 29, 2025 12:39
Comment on lines 186 to 208
```mermaid
graph TB
Title[Workspace Types = Pre-configured Environments]
subgraph WorkspaceTypes
AppType[App Workspace Type<br/>Has: DaaS]
FunctionType[Function Workspace Type<br/>Has: Knative Functions]
ManagementType[Management Type<br/>Has: User Management]
end
Title --> WorkspaceTypes
WorkspaceTypes -->|creates| Team1[App Team Workspace<br/>Can deploy apps]
WorkspaceTypes -->|creates| Team2[Functions Team Workspace<br/>Can create functions]
WorkspaceTypes -->|creates| Team3[Admin Workspace<br/>Can manage users]
Team1 --> Dev1[App Developer<br/>Sees app tools only]
Team2 --> Dev2[Function Developer<br/>Sees function tools only]
Team3 --> Admin1[Administrator<br/>Sees admin tools only]
```
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This graph is confusing to me. It uses both the terms "Workspace Type" and then for the third one, it's just "Type". Also the fact that the subgraph of all types_ is "creating" new workspaces sounds wrong to me.

In general this graph gives the impression of a hierarchy or control flow, when nothing shown in the graph really is a hierarchy. The "App Developer Sees app tools only" box does not logically follow the "App Team Workspace Can deploy apps" box like the arrow implies.

I'm not sure a graph here helps understanding the different personas.

Copy link
Contributor Author

@olamilekan000 olamilekan000 Sep 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This graph is confusing to me. It uses both the terms "Workspace Type" and then for the third one

This is an oversight on my part. I have made corrections.

...Also the fact that the subgraph of all types_ is "creating" new workspaces sounds wrong to me.
In general this graph gives the impression of a hierarchy or control flow, when nothing shown in the graph really is a hierarchy. The "App Developer Sees app tools only" box does not logically follow the "App Team Workspace Can deploy apps" box like the arrow implies.

I didn't intend to make it look hierarchical. It was just based on my understanding. I can update the diagram

Comment on lines +271 to +303
```mermaid
graph TB
Title[API Exporting/Binding = Sharing Tools Between Workspaces/Logical Clusters]
subgraph ToolOwner [Infra: Has Unique Tools]
Infra[Infra Workspace]
SpecialTool[Special Database API <br/>PostgreSQL Operator]
APIExport[API Export <br/> I'm sharing my Database tool]
end
subgraph ToolUsers [App Teams - Need Tools]
AppTeam1[App Team 1 Workspace]
AppTeam2[App Team 2 Workspace]
APIBinding1[API Binding <br/> I want to use Database tool]
APIBinding2[API Binding <br/> I want to use Database tool]
end
Title --> ToolOwner
Infra --> SpecialTool
SpecialTool --> APIExport
APIExport -->|shares with| APIBinding1
APIExport -->|shares with| APIBinding2
APIBinding1 --> AppTeam1
APIBinding2 --> AppTeam2
AppTeam1 --> CanUse1[App Team 1: <br/>can now create PostgreSQL databases]
AppTeam2 --> CanUse2[App Team 2: <br/>can now create PostgreSQL databases]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This graph is even more confusing to me. It shows relations like "the workspace follows/depends on the APIBinding" (?), introduces the "I" persona and talks about "tools" instead of APIs. The usage of a mermaid chart feels very forced to me here.

Also this might be triggering me personally because it reminds me of this banger of a meme an admin friend made over a decade ago:

Image

cc @EX0l0N

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do you think this can be better presented?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could see a sequence diagram that shows the flow from "infra team setting up their service, then their apiexport" and then afterwards the "team discovers api, team binds it, team uses it". Right now the diagram kind of conflates two aspects to me:

  • the "fanning out" aspect, where one service team provides a service to many consumers
  • the sequence of actions that happen from providing to consuming a service

Squeezing both into the same diagram is hard.

@olamilekan000 olamilekan000 force-pushed the add-contextual-diagram-to-terminologies branch from 06194b8 to 1960410 Compare September 30, 2025 09:13
@olamilekan000 olamilekan000 requested a review from xrstf September 30, 2025 09:14
@mjudeikis
Copy link
Contributor

Im just wondering if we should just get shared Canva for Exalidraw and do it there. maintain as much as it's maintainable - it just does its own thing, and it's hard (not impossible, but very hard) to have something clearly explainable using these.

@olamilekan000 if I get one, do you want maybe a collab on those? as I feel we need something that users can grasp from first sight. And this is not it :/

@mjudeikis
Copy link
Contributor

Sorry, diagrams comes just after "naming" as harders problems in IT.

@olamilekan000
Copy link
Contributor Author

Im just wondering if we should just get shared Canva for Exalidraw and do it there. maintain as much as it's maintainable - it just does its own thing, and it's hard (not impossible, but very hard) to have something clearly explainable using these.

@olamilekan000 if I get one, do you want maybe a collab on those? as I feel we need something that users can grasp from first sight. And this is not it :/

I am open to a collab. Do you have a canva workspace we can use? or how do we start? @mjudeikis

@mjudeikis
Copy link
Contributor

Im just wondering if we should just get shared Canva for Exalidraw and do it there. maintain as much as it's maintainable - it just does its own thing, and it's hard (not impossible, but very hard) to have something clearly explainable using these.
@olamilekan000 if I get one, do you want maybe a collab on those? as I feel we need something that users can grasp from first sight. And this is not it :/

I am open to a collab. Do you have a canva workspace we can use? or how do we start? @mjudeikis

sent via DM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dco-signoff: yes Indicates the PR's author has signed the DCO. kind/documentation Categorizes issue or PR as related to documentation. ok-to-test Indicates a non-member PR verified by an org member that is safe to test. release-note-none Denotes a PR that doesn't merit a release note. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants