Replies: 3 comments 5 replies
-
That is up to your interpretation of the use cases. I don't expect many at all. Please look at other charts and what they expose in the schema to learn. Some cross cutting concerns you will see exposed in most of the charts, like resources. If it is a scalable service then it will need resource parameterization. If it is an operator or other simple service that we expect not to scale much, we provide hard defaults. Remember, the schema is only exposing what we deem "simple mode": just enough knobs to start using the application. We also provide "expert mode" to override all settings, but that is not exposed through the schema.
We DO store platform secrets encrypted in the values repo, not in vault. It is handled through sops. Check
In |
Beta Was this translation helpful? Give feedback.
-
Can you start by creating the story in zenhub following the Story template? In the top you could write out the use case(s) we have for this: As an admin, after I deploy otomi for the first time, I expect a working git hosting service to become available (at Then it becomes easier to break down these steps in a sequence diagram, which I recommend you do, and create and keep an image of in the discussion here. From that it becomes much easier to break down these steps into business requirements, and then into functional requirements. |
Beta Was this translation helpful? Give feedback.
-
And may I suggest you rephrase "User stories" to something else? I believe you mean to say something else. (And we will never have work on multiple user stories in one go.) About your last "gitea access" list:
Thinking about this, we would have to provide a mechanism for authentication that can me mapped onto our OIDC approach, IF we want to expose this git hosting service outside the cluster to team members, but that is not in scope of this Story. So for now I would disregard exposure other than over port 80. Only otomi platform will read and write to that one values repo. We will choose http simple auth as mechanism and provide machine credentials for otomi, so that an admin can use these same credentials to pull and push. |
Beta Was this translation helpful? Give feedback.
-
Introduction
This is my first REQ doc, please be kind, it will probably not be complete nor perfect and I'm aware
The goal is to install Gitea into the otomi stack that holds a default
otomi-values
set that the user can use or modify to get access to kubernetes clusters.By having the
otomi-values
inside the otomi stack, making modifications becomes easier (I think). But how are secrets handled? These should be integrated with the vault I assume.I'm opening this discussion to get some answers, and a clearer picture of the tasks ahead. What are the steps going to be during development and the pitfalls to be encountered. Since my knowledge is still small getting more information, black on white (or white on black - whichever you prefer) will help me develop a consise addition to the application
Note:
Code changes: gitea branch
Github issue: #293
Questions
glue
-> giteaUser stories
System Requirements
Gitea storage
Gitea stores the data in a SQL database, most commonly MySQL/MariaDB or PostgreSQL (Gitea DB Docs) and one of these three needs to be selected.
Gitea access
Beta Was this translation helpful? Give feedback.
All reactions