Difference between revisions of "StarlingX/Project Priorities"
(Created page with "=== Project Priorities === The following is an ordered list of our priorities from highest to lowest for the next six months. # Build stability & mirror cache / improvements...") |
|||
| Line 6: | Line 6: | ||
# Basic processes & infrastructure e.g. CI/CD, Test/Validation, Releases, Dev, Bug handling, Security, Devstack, Zuul tests, unit tests, etc…. | # Basic processes & infrastructure e.g. CI/CD, Test/Validation, Releases, Dev, Bug handling, Security, Devstack, Zuul tests, unit tests, etc…. | ||
# Documentation e.g. project map, how to contribute, how to build/install, how to run, how to debug, …. | # Documentation e.g. project map, how to contribute, how to build/install, how to run, how to debug, …. | ||
| − | # Distro management - build, updates, automation, etc... How do we manage the package content? When / how do we upgrade to newer versions? | + | # Distro management - build, updates, automation, etc... How do we manage the package content? When / how do we upgrade to newer versions, newer versions of CentOS? |
| − | # Disposition of StarlingX staging | + | ## We will continually update components for CVE's. |
| − | # Project decoupling | + | ## We want to keep as current (as possible) on key components (kernel, qemu/libvirt, etc...). Is it time to move to CentOS 7.5? To newer versions of qemu/libvirt? Need the list of things to update (drivers, etc..). Bruce to spin up a new sub-projects for CentOS 7.5 and qemu updates |
| + | # Patch backlog analysis and plan to address / close forks | ||
| + | ## Including how many patches per repo - some have very few, can we move to SRPM patches instead of repos? | ||
| + | # Disposition of StarlingX staging - find a long term home for those repos. | ||
| + | ## Long term we want to move away from needing them, but there will always be a set of patches to carry | ||
| + | ## We need a plan for handling our kingbird repo since it's not really kingbird. WR to create new repos that can hopefully be accepted | ||
| + | # Project decoupling - make the services more self contained | ||
# KPI establishment, test automation and on-going improvements | # KPI establishment, test automation and on-going improvements | ||
# Reduce patch backlog - openstack and non-openstack | # Reduce patch backlog - openstack and non-openstack | ||
| + | # Python 3 readiness - new code is python3, repo by repo / file by file work needed. zuul check jobs needed | ||
# Container support | # Container support | ||
## Kubernetes integration | ## Kubernetes integration | ||
| Line 16: | Line 23: | ||
## Support for containerized workloads | ## Support for containerized workloads | ||
# StarlingX Edge initiatives | # StarlingX Edge initiatives | ||
| + | ## Beginnings of support for managing distributed Edge nodes, work being done by Greg in Edge working group | ||
# Telemetry enhancements (collectd and gnocchi integration) | # Telemetry enhancements (collectd and gnocchi integration) | ||
| − | # PTP support | + | # PTP (Precision Time Protocol) support |
| − | # Networking features (containerized VNFs, ONAP integration, TSN, …) | + | # Networking features (containerized VNFs, ONAP integration, TSN (Time Senstive Networking), …) |
# Intel-specific features: SGX, EPID, integrations with Intel platforms and software | # Intel-specific features: SGX, EPID, integrations with Intel platforms and software | ||
| − | # | + | # Package system independence |
# Operating System independence | # Operating System independence | ||
Revision as of 14:43, 19 July 2018
Project Priorities
The following is an ordered list of our priorities from highest to lowest for the next six months.
- Build stability & mirror cache / improvements
- Basic processes & infrastructure e.g. CI/CD, Test/Validation, Releases, Dev, Bug handling, Security, Devstack, Zuul tests, unit tests, etc….
- Documentation e.g. project map, how to contribute, how to build/install, how to run, how to debug, ….
- Distro management - build, updates, automation, etc... How do we manage the package content? When / how do we upgrade to newer versions, newer versions of CentOS?
- We will continually update components for CVE's.
- We want to keep as current (as possible) on key components (kernel, qemu/libvirt, etc...). Is it time to move to CentOS 7.5? To newer versions of qemu/libvirt? Need the list of things to update (drivers, etc..). Bruce to spin up a new sub-projects for CentOS 7.5 and qemu updates
- Patch backlog analysis and plan to address / close forks
- Including how many patches per repo - some have very few, can we move to SRPM patches instead of repos?
- Disposition of StarlingX staging - find a long term home for those repos.
- Long term we want to move away from needing them, but there will always be a set of patches to carry
- We need a plan for handling our kingbird repo since it's not really kingbird. WR to create new repos that can hopefully be accepted
- Project decoupling - make the services more self contained
- KPI establishment, test automation and on-going improvements
- Reduce patch backlog - openstack and non-openstack
- Python 3 readiness - new code is python3, repo by repo / file by file work needed. zuul check jobs needed
- Container support
- Kubernetes integration
- Containerized OpenStack services
- Support for containerized workloads
- StarlingX Edge initiatives
- Beginnings of support for managing distributed Edge nodes, work being done by Greg in Edge working group
- Telemetry enhancements (collectd and gnocchi integration)
- PTP (Precision Time Protocol) support
- Networking features (containerized VNFs, ONAP integration, TSN (Time Senstive Networking), …)
- Intel-specific features: SGX, EPID, integrations with Intel platforms and software
- Package system independence
- Operating System independence
