Proposal to add a guideline to add a service in admin guide
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 2.7k
- Forks
- 554
- Avg merge
- 20h 42m
- Merged PRs (30d)
- 14
Description
What would you like to be added:
A guide note for how to add a service for pai.
Why is this needed:
When I add a docker-cache service by myself, there are many know-hows need to be explained.
- service folder structure
- build(optional), config, deploy
- config folder include docker-cache.yaml and docker_cache.py (if service name is docker-cache)
- docker-cache.yaml will use as jinja template default parameters, {{ cluster_ cfg["docker-cache"]["<param_key>"] }}
- docker_cache.py is a preprocess script to add runtime parameter like pai-master ip
- deploy folder
- service.yaml describe template file need to be generate by jinja, and other meta info for service
- start.sh/stop.sh/refresh.sh/delete.sh wrapped k8s operation for service
- templates for k8s config
- config folder yaml and py script naming convention: py need '_' replace '-'
- deploy folder template {{ }} syntax and cluster-configuration structure: {{ }} to replace by jinja
- deploy folder service.yaml structure
- k8s yaml can't use namespace
Without this feature, how does the current module work:
Components that may involve changes:
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the existing admin guide and the service structure described in the issue, including config, deploy, service.yaml, templates, and the start.sh/stop.sh/refresh.sh/delete.sh scripts. Document the naming conventions, Jinja parameters, cluster-configuration structure, and namespace limitation; done means a newcomer can follow the guide to add a service without relying on undocumented know-how.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, kubernetes, python
- Domain
- devops, documentation
- Issue type
- Documentation
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100