You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Before making a first production-ready release of the API, we need to review the whole design and make changes wherever required accordingly. This top-level issue can be used to keep track of all the different areas of the architecture. We can also take this opportunity to complete a first version of the documentation to cover all the corresponding parts, even if some refinements can be made later on (e.g. between December and March).
Development
Data models
Users and groups
Add explicit list of scopes e.g. admin rather than relying on magic group names
Consider "group admins" with admin rights but only with a user group
Node
Group vs Job
Compare against KCIDB schema
Revision (consider patch sets)
API endpoints
Names and arguments: consistency, simplicity, security
Data schema for input / output: mainly models but additional ones e.g. user profile
Operators
Publisher / Subscriber
User / ownership
Unique messages (e.g. for load balancing) vs "broadcast"
Avoid leaks: keeping track of open channels on the API side in Redis and add endpoint to query it
Node states
Consider using open or submitted when a node has just been created
kci command line tool
Settings and YAML config arguments
Overall user experience
Results browser (currently kci show results)
Offline mode relying only on JSON files
Commands to create / edit nodes from scratch either in API or in local JSON
Add monitor command to monitor events (kci show events?)
kernelci Python package versioned release
Pipeline system services
Trigger
Tarball
Scheduler
Regression tracking
Timeouts
Email report generator (depends on kernelci.email to be implemented...)
Sysadmin
Deployment of services
Main API service (FastAPI)
Redis
MongoDB
Storage
Pipeline services
LAVA callback handler
SSL certificates management
DNS updates
Database backup / archiving
Storage auto clean-up
Application updates
Monitoring
Costs breakdown
The text was updated successfully, but these errors were encountered:
Before making a first production-ready release of the API, we need to review the whole design and make changes wherever required accordingly. This top-level issue can be used to keep track of all the different areas of the architecture. We can also take this opportunity to complete a first version of the documentation to cover all the corresponding parts, even if some refinements can be made later on (e.g. between December and March).
Development
admin
rather than relying on magic group namesopen
orsubmitted
when a node has just been createdkci
command line toolkci show results
)kci show events
?)kernelci
Python package versioned releasekernelci.email
to be implemented...)Sysadmin
The text was updated successfully, but these errors were encountered: