93acffc3b8
The previous 'Help Most Needed' list was presenting information in a way that focused on the desires of the community rather than the value that sponsoring organisations can generate - for both themselves and the commons. Replace the list with a new list of 'Upstream Investment Opportunities', and a process to keep them current by removing them after they have been on the list for between 6 months and a year, so that the submitter is forced to reaffirm their interest and the TC is forced to re-evaluate the relevancy. Since the current 'Help Most Needed' entries are generally not written in a style emphasising the value to a business of investing, the initial list is empty and will be filled as the TC evaluates business cases according to its new criteria and understanding of the needs of potential contributing organisations. To preserve the existing information, the contents of the current 'Help Most Needed' list appear as the 2018 upstream investment opportunites. Links to the old list will temporarily redirect here until such time as the new entries are in place, at which point we can redirect to the main page with the latest index. Change-Id: I65fef701dc2e3d50aa84e7ee79b068c78346c846
3.5 KiB
Unified Limits and Quota Management
Description
Most OpenStack services allow users to manage a resource, or a group of resources, via an API. Operators use limits to ensure users are getting the resources they pay for and need for their cloud use cases. These limits and quotas are imperative to accurate billing, settings up price structure, maximizing hardware usage, and ensuring resources are distributed throughout the deployment as operators see fit.
Currently, there isn't a unified approach to limits across OpenStack services. Services that do have an API for managing resource limits share a commonality in the implementation but still suffer from inconsistencies. It is considered risky to implement limit management separately across services since the hierarchical nature of project namespaces in OpenStack can be complicated. This forces developers to solve the same hard problem over and over again. This design leaves limit API consistency across OpenStack up to the developers from each project and hoping they all implement public APIs the same way. There is work underway to consolidate the management of limits to a single service, making it consumable to other services in the deployment while minimizing the risk of deviating implementations in ways that negatively impact end users and operators.
Value
Improved Manageability
By implementing a unified approach to limits, operators can efficiently manage and view resource limits and quota across a deployment. Today, that experience is fragmented and requires operators to query services individually if they support limits. A unified limit interface allows operators to be more efficient since they don't have to aggregate resource limits and information manually, or by maintaining separate tooling and scripts to do it for them.
Consistent Interfaces
End users and operators benefit from a consistent interface. This reduces the ability for interfaces to develop differences by using a centralized, unified limit API. End users and operators expect the same experience regardless of the resource, or which service controls that resource. Ensuring consistency reduces cognitive load on behalf of the user and allows for a better experience with the software.
Resource Flexibility
A unified approach, where limits are defined in a consistent place and consumed across services makes it easier to implement validation of resource limits. This flexibility is powerful for operators in modeling how available resources should, or should not, flow between projects. For example, a deployment interested in maximizing resource utilization may choose to let free resource flow between peer projects. This allows resources to move from stable projects to ones that are more resource-intensive.
Reduced Complexity
OpenStack's support for hierarchical multi-tenancy makes associating limits across projects challenging. With unified limits, we're minimizing the area for mistakes by allowing developers to reuse common code. Reuse reduces potential complexity by isolating complicated logic into a few key places, instead of duplicating it across many services. This reduction makes it less likely for services to develop implementations or public facing APIs that deviate, even slightly, from one another.
Contact
For questions about getting involved with this initiative, reach out to the OpenStack Discuss mailing list.