jeffmccune
commented
7 months ago Closing this as specified in my Holos Project Reference note.
2024-03-19 #holos-project #holos
This document is a reference specification of a Holos Project. The purpose of a Project is to give a Project Owner the ability to manage resources for their project with appropriate access.
Issue: Project Specification
Roles and Responsibilities
Project Owner
A team lead responsible for delivering a project to the business to provide value for customers. Responsible for:
- Creating a project.
- Deleting a project.
- Allocating budget for a project.
- Assigning members to the project.
- Defining roles and responsibilities for project members.
Project Developer
An software developer operating as an individual contributor to a project. Responsible for:
- Publishing code for review
- Reviewing code
- Fixing unit tests
- Working in the lower dev or stage environments
Project Members
Project members are responsible for:
- The contents of a project database. Schema, data within, etc.
- Any backup schedule other than the default.
- Project specific dashboards.
- Project specific run books.
Cluster Admin
Also known as a Platform Admin or Platform Engineer. Operational role focused on managing and operating the platform and clusters within the platform.
Security Reviewer
Security reviewers are responsible for defining security guidelines and auditing how close or far a project is from the guidelines. Security Reviewers and admin work in concert with project members to define and implement controls.
Project Stages
A project has a small number of stages resources operate within.
| Stage | Label | Description |
|---|---|---|
| Production | prod | For live, production workloads |
| Development | dev | For development and testing of new features or bug fixes |
| Staging | stage | Optional staging environment to solicit customer feedback before going to production. |
Project Environments
Each project stage contains one or more environments. Generally prod only has one environment also named prod. Development, however, may have many environments, one for each individual contributor. The purpose of multiple environments in the development stage is for rapid iteration.
Changes are promoted from individual sandbox environments to the shared dev environment to production.
| Environment | Stage | Label | Description |
|---|---|---|---|
| prod | prod | prod | Production environment |
| dev | dev | dev | Development environment shared by the team |
| jeff | dev | jeff | Jeff's sandbox |
| gary | dev | gary | Gary's sandbox |
| nate | dev | nate | Nate's sandbox |
Project Resources
When a project is created the following resources are created in the platform.
Namespaces
Namespace names take the form <env>-<project>-<component> where a project may reflect a single service or a larger collection of services. A component may also reflect a service or a smaller piece of a larger service.
The following namespaces are defined by the platform and created when a Project Owner creates a project. Standard resources and IAM polices are applied, but may be customized by project owners in collaboration with Cluster Admins.
For this example consider an iam project for the purpose of identity and access management. The primary service of the project is an OIDC identity provider which requires a PostgreSQL database.
For this exercise the project is iam and the service is zitadel
prod-iam-system
Auth Proxy
Deployment/oauth2-proxy Deployment/redis
Observability
Need to explore if it's worth setting up a per-project obs stack or if the cluster stack should be used instead.
- Prometheus?
- Grafana?
prod-iam-zitadel
Production access to the primary service for the project.
- Postgres Database
- pgAdmin Database UI
- Backup Configuration
- Restore Runbook
- Roles
- RolesBindings
- Deployment
- Service
- VirtualService
- AuthorizationPolicy
The above resources are created for each environment. Optionally, in a lower environment they may be omitted and allowed to be configured directly by the developer.
Promotion
In a lower environment, like jeff-iam-zitadel few resources are managed in the individual contributor's namespace. The tooling allows the IC to rendere yaml and apply it directly to the cluster in their sandbox namespace.
For example, the standard set of resources is available and managed by default but may be disabled and modified for promotion.
- Postgres Database
- pgAdmin Database UI
- Backup Configuration
- Restore Runbook
- Roles
- RolesBindings
- Deployment
- Service
- VirtualService
- AuthorizationPolicy
Context: We need a specification for what a Project in holos is so we can prioritize what to work on for the MVP and rank the implementation of the project elements.