Convert 'Help Most Needed' to 'Upstream Investment Opportunities'
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
This commit is contained in:
Zane Bitter
parent
4bff6be36a
commit
93acffc3b8
14
CHAIR.rst
14
CHAIR.rst
|
|
@ -158,3 +158,17 @@ https://www.openstack.org/assets/reports/OpenStack-AnnualReport2017.pdf
|
|||
for one example report and
|
||||
https://etherpad.openstack.org/p/openstack-2018-annual-report for the
|
||||
working notes for the 2018 report.
|
||||
|
||||
Upstream Investment Opportunities
|
||||
=================================
|
||||
|
||||
https://governance.openstack.org/tc/reference/upstream-investment-opportunities/index.html
|
||||
|
||||
Toward the end of each calendar year, invite sponsors of the current year's
|
||||
Upstream Investement Opportunities to repropose any relevant ones for the
|
||||
following year. Solicit new entries on the mailing list.
|
||||
|
||||
At the beginning of the new year, switch the index to point at the directory
|
||||
for the new year. (If no business cases have been approved yet, seed it with a
|
||||
symlink to the template - this can be removed once there are entries in the
|
||||
list.)
|
||||
|
|
|
|||
|
|
@ -1,2 +1,3 @@
|
|||
redirect 301 /tc/reference/top-5-help-wanted.html /tc/reference/help-most-needed.html
|
||||
redirect 301 /tc/reference/top-5-help-wanted.html /tc/reference/upstream-investment-opportunities/2018/index.html
|
||||
redirect 301 /tc/reference/help-most-needed.html /tc/reference/upstream-investment-opportunities/2018/index.html
|
||||
redirect 301 /tc/resolutions/2018-03-19-sig-governance.html /tc/resolutions/20180319-sig-governance.html
|
||||
|
|
|
|||
|
|
@ -1,2 +1,3 @@
|
|||
/tc/reference/top-5-help-wanted.html 301 /tc/reference/help-most-needed.html
|
||||
/tc/reference/top-5-help-wanted.html 301 /tc/reference/upstream-investment-opportunities/2018/index.html
|
||||
/tc/reference/help-most-needed.html 301 /tc/reference/upstream-investment-opportunities/2018/index.html
|
||||
/tc/resolutions/2018-03-19-sig-governance.html 301 /tc/resolutions/20180319-sig-governance.html
|
||||
|
|
|
|||
|
|
@ -1,572 +0,0 @@
|
|||
=========================
|
||||
'Help most needed' list
|
||||
=========================
|
||||
|
||||
This document lists at most 5 areas where the OpenStack Technical Committee
|
||||
seeks contributions to significantly help OpenStack as a whole. While in most
|
||||
cases things happen naturally through the normal contribution dynamics
|
||||
in the community, in some cases a `tragedy of the commons`_ is at play.
|
||||
Guidance, leadership and proper recognition of efforts is therefore needed
|
||||
to encourage individuals or organizations to contribute in areas where they
|
||||
could make a big impact.
|
||||
|
||||
Each item should clearly explain why the item matters (value of the effort
|
||||
to the community, operators and users), why we need help there (description
|
||||
of the current situation) and what experience or benefit the volunteer can
|
||||
expect to gain from tackling it. It should also include the name of a TC
|
||||
sponsor (responsible for evangelizing, articulating and channelling the work,
|
||||
but also facilitating connections between candidates and target teams). For
|
||||
an estimate of the commitment required, interested candidates should reach
|
||||
out to the TC sponsor, or the PTL of the affected project.
|
||||
|
||||
******************
|
||||
Intended Audiences
|
||||
******************
|
||||
|
||||
This document was written with at least two audiences in mind.
|
||||
|
||||
The first audience consists of contributors who would be working on the items
|
||||
listed here. Each item should provide a descriptive summary that helps
|
||||
developers grasp the overall problem and possibly how to solve it or
|
||||
contribute.
|
||||
|
||||
The second audience is corporate or business sponsors. Ultimately, this
|
||||
audience consists of people who have the ability to delegate resources to work
|
||||
on various initiatives. The description of each item should justify why the
|
||||
item is on the list. Descriptions should refrain from being overly technical.
|
||||
Additionally, business sponsors will find the "Value" section beneficial
|
||||
because it describes how investing resources helps reduce maintenance cost,
|
||||
increase interoperability, provide stability, or deliver value to your
|
||||
customers. Essentially, this section should help businesses understand what
|
||||
they are getting out of the investment.
|
||||
|
||||
Both audiences will find the contact information supplied with each item useful
|
||||
for connecting with the right group of people to get resources up-to-speed.
|
||||
|
||||
.. _`tragedy of the commons`: https://en.wikipedia.org/wiki/Tragedy_of_the_commons
|
||||
|
||||
|
||||
1. Documentation owners
|
||||
=======================
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
The #1 pain point in OpenStack, for contributors and users alike, is
|
||||
complexity. While cutting down complexity everywhere we can is critical;
|
||||
proper documentation is essential in addressing that complexity. It directly
|
||||
benefits operators and users of OpenStack, but also facilitates ramping up new
|
||||
direct contributors to the project itself.
|
||||
|
||||
The documentation team has been struggling with limited resources since the
|
||||
dawn of OpenStack, despite the heroic efforts of previous team members. The
|
||||
community outlined an ambitious `plan`_ to decentralize the Documentation team,
|
||||
turning it into a guidance and mentoring support team. To be successful,
|
||||
project teams need to own their documentation, which means that the role of
|
||||
documentation owners will be critical.
|
||||
|
||||
Volunteers for this role will drive this ambitious transition, by being members
|
||||
of their project team and members of the new decentralized documentation team.
|
||||
On the long-term, they will become a reference go-to person in their project,
|
||||
and respected mentors in the OpenStack community.
|
||||
|
||||
Value
|
||||
-----
|
||||
|
||||
Increased Operational Efficiency
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Documentation naturally disseminates knowledge, but it should also be easy for
|
||||
readers to find what they are looking for. This process reduces bottlenecks on
|
||||
human resources and support by allowing users, operators, and contributors to
|
||||
find answers to questions themselves. Less time spent answering common
|
||||
questions means more time focusing on more complicated requests, maintenance,
|
||||
and code.
|
||||
|
||||
Faster Onboarding
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
Contributors come from all different backgrounds and experiences. As a result,
|
||||
they often share similar questions about high-level concepts or processes used
|
||||
within the OpenStack community or components. Consistently documenting
|
||||
processes enables contributors without requiring them to pull tribal knowledge
|
||||
from an existing developer. This documentation fast-tracks contributors to
|
||||
making productive contributions.
|
||||
|
||||
Consistency
|
||||
~~~~~~~~~~~
|
||||
|
||||
Users, customers, and operators are required to reference a vast pool of
|
||||
documentation spread across multiple repositories and sites. Implementing
|
||||
consistency in wording, format, content, and location provides readers with a
|
||||
first-class experience. Additionally, users build confidence and trust in
|
||||
software when it is well documented.
|
||||
|
||||
Contact
|
||||
-------
|
||||
|
||||
For questions about getting involved with this initiative, reach out to the
|
||||
OpenStack Discuss mailing `list`_. You may also contact the `Documentation`_
|
||||
PTL or the Technical Committee sponsor for this item (dhellmann).
|
||||
|
||||
.. _`plan`: https://review.opendev.org/#/c/472275/
|
||||
.. _`list`: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
|
||||
.. _`Documentation`: https://governance.openstack.org/tc/reference/projects/documentation.html
|
||||
|
||||
2. Community Infrastructure Sysadmins
|
||||
=====================================
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
The :ref:`project-infrastructure` team is responsible for designing,
|
||||
building and maintaining the systems that are used in the day to day
|
||||
operation of the OpenStack project as a whole; this includes
|
||||
development, testing, and collaboration tools. All of the software
|
||||
it runs is open source, and under public configuration management so
|
||||
that everyone in the community has the opportunity to participate.
|
||||
One very effective way to get involved in OpenStack, gaining a deep
|
||||
understanding of and visibility within the community, is by helping
|
||||
operate this infrastructure. Attrition due to shifts in employment
|
||||
or availability of personal time impacts the team's ability to
|
||||
support the community effectively, and so there is a constant need
|
||||
for new contributors who can commit to investing sufficient effort
|
||||
to overcome the steep learning curve associated with these varied
|
||||
technologies.
|
||||
|
||||
Because our community is global, its support needs span most
|
||||
timezones. Unfortunately, the bulk of long-term contributors to
|
||||
Infrastructure are concentrated in the Americas and so this leaves
|
||||
APAC and EMEA community members with far fewer options for immediate
|
||||
assistance with urgent issues. Gaining more contributors who are
|
||||
active during those times (whether they live in those parts of the
|
||||
World or not) would provide a substantial benefit to the community.
|
||||
This is not necessarily as easy as it sounds because it's harder to
|
||||
get as much overlap with the current bulk of the team for shadowing
|
||||
and knowledge transfer, but there are still some existing team
|
||||
members in those timezones who can help mitigate that somewhat.
|
||||
|
||||
In particular, the team seeks developers and systems administrators
|
||||
with a background both in maintaining Unix/Linux servers and free
|
||||
software, and places heavy emphasis on systems automation and
|
||||
configuration management (primarily Ansible and Puppet at the
|
||||
moment). Everything possible goes through code review, and gets
|
||||
extensively documented and communicated with the rest of the
|
||||
community over IRC and mailing lists. Server resources are donated
|
||||
by companies operating OpenStack services so there is
|
||||
substantial opportunity both for people who have experience in those
|
||||
technologies as well as anyone wishing to gain more familiarity with
|
||||
them.
|
||||
|
||||
Value
|
||||
-----
|
||||
|
||||
Reusability
|
||||
~~~~~~~~~~~
|
||||
|
||||
The infrastructure team leverages resources donated from companies operating
|
||||
OpenStack services. The community uses the software it produces as a tool for
|
||||
testing it. Every day, contributors submit thousands of patches for review.
|
||||
Infrastructure tools deploy each patch and test it against thousands of tests
|
||||
and scenarios. This volume provides an opportunity to improve the software we
|
||||
write by giving us first-hand experience with issues at scale. The benefit of
|
||||
fixing these issues for the OpenStack CI system is two-fold:
|
||||
|
||||
1. It makes the test platform more stable and robust
|
||||
2. Products or services benefits from the fix being applied upstream
|
||||
|
||||
Don't Repeat Yourself or Your Testing (DRY)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The culture built around extensive testing in OpenStack makes it easier for us
|
||||
to trust patches proposed for review. We've integrated this culture into our
|
||||
review process. Duplicating a social and technical CI system of this size takes
|
||||
incredible amounts of time, people, and patience. Bolstering the CI system we
|
||||
already have in place allows you to focus on testing that is specific to your
|
||||
product or service.
|
||||
|
||||
Immediate Feedback
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The OpenStack CI system is the backbone of feedback for contributors and
|
||||
operators. Users get this feedback early, ideally before the patch lands.
|
||||
Ensuring early feedback through a robust CI system and testing means fewer
|
||||
surprises down the road when you attempt to integrate your product into a new
|
||||
release or deploy a new version of a service.
|
||||
|
||||
Contact
|
||||
-------
|
||||
|
||||
Join the #openstack-infra channel on the Freenode IRC network or reach out
|
||||
through the openstack-infra mailing lists on lists.openstack.org if you would
|
||||
like to get involved. It’s a rewarding chance to learn and help others, but
|
||||
most of all it’s fun! The Technical Committee sponsor for this initiative is
|
||||
Jeremy Stanley (fungi).
|
||||
|
||||
3. Designate Contributors
|
||||
=========================
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
`Designate`_ is a service that manages DNS Zones and Recordsets. It supports
|
||||
multiple DNS Servers, and DNS Service Providers, making it vital for any
|
||||
network or web-based application.
|
||||
|
||||
They need contributors to help find and fix bugs, develop new features, and
|
||||
help maintain the quality of the project, including cross-project initiatives.
|
||||
Designate is quite stable, with any new features requiring long term planning,
|
||||
design, and phased implementation.
|
||||
|
||||
Designate welcomes everyone, from someone starting in the community to senior
|
||||
contributors who want new, interesting problems to tackle. Contributors will
|
||||
get to work on a project that will be a central part of any OpenStack
|
||||
deployment and work on a project that needs to scale from a small single node
|
||||
install to a system controlling DNS servers worldwide.
|
||||
|
||||
Value
|
||||
-----
|
||||
|
||||
Flexibility
|
||||
~~~~~~~~~~~
|
||||
|
||||
DNS is fundamental in gracefully directing users and applications to services.
|
||||
It allows the flexibility to replace underlying hardware while presenting
|
||||
consumers with a consistent endpoint. Designate provides this flexibility to
|
||||
operators and end users.
|
||||
|
||||
Designate supports a wide range of drivers for various `DNS servers`_ and
|
||||
providers, which allows deployers to integrate Designate into pre-existing
|
||||
DNS infrastructures.
|
||||
|
||||
Self-Service
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Self-serviceability is a core tenet of OpenStack `technical vision`_. Designate
|
||||
helps OpenStack clouds adhere to that principle by exposing DNS functionality
|
||||
directly to end-users. Designate allows cloud operators to delegate the control
|
||||
of DNS zones to end users, to avoid complex ticket based workflows for DNS
|
||||
updates.
|
||||
|
||||
|
||||
User Experience
|
||||
---------------
|
||||
|
||||
When end users are building applications in a cloud native way, relying on
|
||||
external tooling to provision DNS entries adds complexity. With the advancement
|
||||
of IPv6, services required to have DNS entries, to avoid application user
|
||||
confusion.
|
||||
|
||||
Designate adds an important part of the value add for cloud infrastructure,
|
||||
and ensures that OpenStack has feature parity with other cloud providers.
|
||||
|
||||
|
||||
Integrations
|
||||
------------
|
||||
|
||||
Designate integrates with many other tools to allow for zero touch management
|
||||
of DNS Zones and Records. The integration with neutron allows admins to have
|
||||
PTR records (for reverse DNS lookups) managed for Floating IP ranges, without
|
||||
giving direct privileged access to the reverse zone to users.
|
||||
|
||||
Tools like `letsencrypt certbot`_ allow for auto provisioning of SSL certs
|
||||
using DNS-01 validation, while tools like `Heat`_, `Terraform`_ and `Ansible`_
|
||||
allow for the provisioning of DNS Zones and Records to be integrated into
|
||||
pre-existing workflows for applications.
|
||||
|
||||
Kubernetes `external-dns`_ support adds simple annotation based DNS management for
|
||||
applications running in kubernetes clusters with load balancers or ingress
|
||||
support.
|
||||
|
||||
Consistency
|
||||
~~~~~~~~~~~
|
||||
|
||||
The OpenStack community continues to evolve, and this evolution requires large
|
||||
cross-project initiatives. Furthermore, users and operators expect consistency
|
||||
across the OpenStack platform. Examples from recent history include
|
||||
OpenStack-wide support for `Python 3`_ and easing operator pain by moving
|
||||
`policy configuration`_ into code. Ensuring Designate stays up-to-date with
|
||||
these initiatives is imperative in reducing operational costs, complexity, and
|
||||
user frustration.
|
||||
|
||||
Contact
|
||||
-------
|
||||
|
||||
If you are interested, please join #openstack-dns on Freenode or contact the
|
||||
Designate PTL (Graham Hayes - mugsie), the Technical Committee sponsor (TBD).
|
||||
You may also email the openstack discuss mailing list with the tag [designate]
|
||||
in the subject.
|
||||
|
||||
.. _`Designate`: https://governance.openstack.org/tc/reference/projects/designate.html
|
||||
.. _`DNS servers`: https://docs.openstack.org/designate/latest/admin/support-matrix.html
|
||||
.. _`technical vision`: https://governance.openstack.org/tc/reference/technical-vision.html
|
||||
.. _`letsencrypt certbot` : https://pypi.org/project/certbot-dns-openstack/
|
||||
.. _`Heat`: https://docs.openstack.org/heat/rocky/template_guide/openstack.html#OS::Designate::RecordSet
|
||||
.. _`Terraform`: https://www.terraform.io/docs/providers/openstack/r/dns_recordset_v2.html
|
||||
.. _`Ansible`: https://docs.ansible.com/ansible/latest/modules/os_zone_module.html#os-zone-module
|
||||
.. _`external-dns`: https://github.com/kubernetes-incubator/external-dns
|
||||
.. _`Python 3`: https://governance.openstack.org/tc/goals/stein/python3-first.html
|
||||
.. _`policy configuration`: https://governance.openstack.org/tc/goals/queens/policy-in-code.html
|
||||
.. _`list`: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
|
||||
|
||||
4. Glance Contributors
|
||||
======================
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
`Glance`_ is a service to manage disk images for OpenStack clouds. It was one
|
||||
of the first projects developed in the OpenStack ecosystem. Nearly every
|
||||
OpenStack deployment contains a Glance service. Without Glance, Nova cannot
|
||||
create servers.
|
||||
|
||||
Glance is looking for new contributors who would be willing to provide reviews,
|
||||
to work on bugs, or to work on new features. Glance has welcomed interns,
|
||||
junior developers, and more senior developers. In every case, it is a great way
|
||||
to grow and contribute to OpenStack.
|
||||
|
||||
Value
|
||||
-----
|
||||
|
||||
Maintenance Costs
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
Glance is a critical service in OpenStack. Contributions to the future of the
|
||||
image registry are essential to the stability of OpenStack. More importantly,
|
||||
Glance is not feature-complete. There is significant technical debt that needs
|
||||
to be taken care of and several features to implement.
|
||||
|
||||
Consistency
|
||||
~~~~~~~~~~~
|
||||
|
||||
The OpenStack community continues to evolve, and this evolution requires large
|
||||
cross-project initiatives. Furthermore, users and operators expect consistency
|
||||
across the OpenStack platform. Examples from recent history include
|
||||
OpenStack-wide support for `Python 3`_ and easing operator pain by moving
|
||||
`policy configuration`_ into code. Ensuring Glance stays up-to-date with these
|
||||
initiatives is imperative in reducing operational costs, complexity, and user
|
||||
frustration.
|
||||
|
||||
Contact
|
||||
-------
|
||||
|
||||
Interested? Join the Glance IRC channel (#openstack-glance) or reach out to the
|
||||
OpenStack discuss `mailing list`_ using the `[glance]` tag.
|
||||
|
||||
.. _`Glance`: https://governance.openstack.org/tc/reference/projects/glance.html
|
||||
.. _`Python 3`: https://governance.openstack.org/tc/goals/stein/python3-first.html
|
||||
.. _`policy configuration`: https://governance.openstack.org/tc/goals/queens/policy-in-code.html
|
||||
.. _`mailing list`: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
|
||||
|
||||
5. Goal Champions
|
||||
=================
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
As OpenStack matures, large initiatives linger that affect the community as a
|
||||
whole. Like with any large body of work, someone needs to step up and
|
||||
coordinate the group, keep track of progress, call for and chair regular
|
||||
meetings, and publish status updates. PTLs do this work for project teams,
|
||||
leaders do it for various cross-project working groups and SIGs, and champions
|
||||
do it to help us complete :ref:`release-cycle-goals` over a cycle.
|
||||
Additionally, efficient coordination is one of the most productive ways to get
|
||||
things done, especially in large communities.
|
||||
|
||||
The work of those champions is essential to the success of OpenStack, and yet
|
||||
it is often challenging to find volunteers for those positions. Contributing as
|
||||
a goal champion takes time (several hours per week), and that commitment needs
|
||||
to be properly recognized and celebrated.
|
||||
|
||||
Volunteers for this role will make a direct impact on the productivity of
|
||||
others, become respected leaders in OpenStack community, build influence among
|
||||
their peers, and make great candidates for future elected leadership positions
|
||||
in OpenStack.
|
||||
|
||||
Value
|
||||
-----
|
||||
|
||||
Opportunity for Influence
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
As a sponsor or partial sponsor of a community-wide initiative, you have the
|
||||
opportunity to influence the decision-making process. This influence is
|
||||
particularly true if you have existing workarounds or have attempted
|
||||
alternative solutions, both of which are essential perspectives to have in the
|
||||
goal selection process.
|
||||
|
||||
Early Adoption
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
By sponsoring a community goal champion, you have someone in-house to answer
|
||||
questions about the ongoing work and decision making process upstream. This can
|
||||
be an excellent resource in minimizing disruption to downstream products and
|
||||
services, especially tracking a large piece of work across services and
|
||||
projects.
|
||||
|
||||
Contact
|
||||
-------
|
||||
|
||||
If you are interested in helping with community goals, contact the Technical
|
||||
Committee sponsor for this item (dhellmann).
|
||||
|
||||
6. 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
|
||||
<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss>`_.
|
||||
|
||||
7. Consistent Role Based Access Control
|
||||
=======================================
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
OpenStack is comprised of APIs that allow users to manage physical and virtual
|
||||
infrastructure. Contributors wrote these APIs for end users and operators
|
||||
alike. With tenancy being a pillar of OpenStack's technical vision, ensuring
|
||||
isolation between users and layers of the infrastructure is imperative to
|
||||
OpenStack's long-term success.
|
||||
|
||||
The OpenStack project has grown a tremendous amount of functionality over the
|
||||
last several years. Unfortunately, evolution in the way services protect their
|
||||
APIs failed to maintain pace with feature development. As a result, services
|
||||
today do not protect APIs in ways that expose functionality effectively to
|
||||
users, support security requirements, reduce operational complexity for
|
||||
operators, or aid interoperability.
|
||||
|
||||
Since the Pike release, there has been renewed efforts to improve tools and
|
||||
libraries for contributors to use to correct these issues.
|
||||
|
||||
Value
|
||||
-----
|
||||
|
||||
Increased Functionality
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Currently, most OpenStack services have a very binary approach to RBAC
|
||||
enforcement. This approach usually handicaps new functionality from being
|
||||
exposed to users because users typically do not fall in one of two camps.
|
||||
Contributors either need to lock down the feature to only system
|
||||
administrators, or open it up to nearly every user in the deployment. This is
|
||||
especially true for APIs that expose details about multiple tenants.
|
||||
|
||||
Implementing better API protection allows contributors to expose more
|
||||
functionality to end users and operators by default. Lowering the bar for users
|
||||
to access a feature means more opportunities for feedback loops, more end users
|
||||
getting access to the functionality they need, and makes OpenStack more usable
|
||||
overall.
|
||||
|
||||
Enhanced Security
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
OpenStack has a wide variety of users. Auditing APIs and adjusting default
|
||||
access control increases security across the entire OpenStack platform. This
|
||||
exercise gives contributors the ability to provide secure defaults for new
|
||||
deployments. Reasonable default values that are inherently secure makes it
|
||||
easier for organizations with strict security requirement to deploy OpenStack.
|
||||
|
||||
Reduced Operational Complexity
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Today's RBAC enforcement implementation lacks secure defaults, but it is
|
||||
somewhat configurable. Deployments that must have a more secure enforcement
|
||||
implementation are forced to maintain arduously complex configuration files.
|
||||
Furthermore, many organizations re-implement similar use cases.
|
||||
|
||||
Interoperability
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Because policy configuration gives deployments the flexibility to maintain
|
||||
complicated policies at their own expense, it is common to see many
|
||||
organizations solve the same problem. Unfortunately, it's unlikely many of them
|
||||
are sharing the same solution. This pattern impedes interoperability between
|
||||
deployments, making it frustrating for users interacting with different
|
||||
OpenStack clouds.
|
||||
|
||||
Offering a reasonable set of roles and implementing basic RBAC improves
|
||||
interoperability by not requiring each organization to solve the same problem
|
||||
individually.
|
||||
|
||||
Contact
|
||||
-------
|
||||
|
||||
For more information on how to contribute to this initiative, please read the
|
||||
`authorization documentation`_ dedicated to describing the problem.
|
||||
For questions about getting involved with this initiative, reach out to the
|
||||
OpenStack Discuss mailing `list`_.
|
||||
|
||||
.. _authorization documentation: https://docs.openstack.org/keystone/latest/contributor/services.html#why-are-authorization-scopes-important
|
||||
.. _list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
|
||||
|
|
@ -13,7 +13,7 @@ Reference documents which need to be revised over time.
|
|||
projects/index
|
||||
popup-teams
|
||||
technical-vision
|
||||
help-most-needed
|
||||
upstream-investment-opportunities/index
|
||||
role-of-the-tc
|
||||
new-projects-requirements
|
||||
new-language-requirements
|
||||
|
|
|
|||
|
|
@ -0,0 +1,89 @@
|
|||
Community Infrastructure Sysadmins
|
||||
==================================
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
The :ref:`project-infrastructure` team is responsible for designing,
|
||||
building and maintaining the systems that are used in the day to day
|
||||
operation of the OpenStack project as a whole; this includes
|
||||
development, testing, and collaboration tools. All of the software
|
||||
it runs is open source, and under public configuration management so
|
||||
that everyone in the community has the opportunity to participate.
|
||||
One very effective way to get involved in OpenStack, gaining a deep
|
||||
understanding of and visibility within the community, is by helping
|
||||
operate this infrastructure. Attrition due to shifts in employment
|
||||
or availability of personal time impacts the team's ability to
|
||||
support the community effectively, and so there is a constant need
|
||||
for new contributors who can commit to investing sufficient effort
|
||||
to overcome the steep learning curve associated with these varied
|
||||
technologies.
|
||||
|
||||
Because our community is global, its support needs span most
|
||||
timezones. Unfortunately, the bulk of long-term contributors to
|
||||
Infrastructure are concentrated in the Americas and so this leaves
|
||||
APAC and EMEA community members with far fewer options for immediate
|
||||
assistance with urgent issues. Gaining more contributors who are
|
||||
active during those times (whether they live in those parts of the
|
||||
World or not) would provide a substantial benefit to the community.
|
||||
This is not necessarily as easy as it sounds because it's harder to
|
||||
get as much overlap with the current bulk of the team for shadowing
|
||||
and knowledge transfer, but there are still some existing team
|
||||
members in those timezones who can help mitigate that somewhat.
|
||||
|
||||
In particular, the team seeks developers and systems administrators
|
||||
with a background both in maintaining Unix/Linux servers and free
|
||||
software, and places heavy emphasis on systems automation and
|
||||
configuration management (primarily Ansible and Puppet at the
|
||||
moment). Everything possible goes through code review, and gets
|
||||
extensively documented and communicated with the rest of the
|
||||
community over IRC and mailing lists. Server resources are donated
|
||||
by companies operating OpenStack services so there is
|
||||
substantial opportunity both for people who have experience in those
|
||||
technologies as well as anyone wishing to gain more familiarity with
|
||||
them.
|
||||
|
||||
Value
|
||||
-----
|
||||
|
||||
Reusability
|
||||
~~~~~~~~~~~
|
||||
|
||||
The infrastructure team leverages resources donated from companies operating
|
||||
OpenStack services. The community uses the software it produces as a tool for
|
||||
testing it. Every day, contributors submit thousands of patches for review.
|
||||
Infrastructure tools deploy each patch and test it against thousands of tests
|
||||
and scenarios. This volume provides an opportunity to improve the software we
|
||||
write by giving us first-hand experience with issues at scale. The benefit of
|
||||
fixing these issues for the OpenStack CI system is two-fold:
|
||||
|
||||
1. It makes the test platform more stable and robust
|
||||
2. Products or services benefits from the fix being applied upstream
|
||||
|
||||
Don't Repeat Yourself or Your Testing (DRY)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The culture built around extensive testing in OpenStack makes it easier for us
|
||||
to trust patches proposed for review. We've integrated this culture into our
|
||||
review process. Duplicating a social and technical CI system of this size takes
|
||||
incredible amounts of time, people, and patience. Bolstering the CI system we
|
||||
already have in place allows you to focus on testing that is specific to your
|
||||
product or service.
|
||||
|
||||
Immediate Feedback
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The OpenStack CI system is the backbone of feedback for contributors and
|
||||
operators. Users get this feedback early, ideally before the patch lands.
|
||||
Ensuring early feedback through a robust CI system and testing means fewer
|
||||
surprises down the road when you attempt to integrate your product into a new
|
||||
release or deploy a new version of a service.
|
||||
|
||||
Contact
|
||||
-------
|
||||
|
||||
Join the #openstack-infra channel on the Freenode IRC network or reach out
|
||||
through the openstack-infra mailing lists on lists.openstack.org if you would
|
||||
like to get involved. It’s a rewarding chance to learn and help others, but
|
||||
most of all it’s fun! The Technical Committee sponsor for this initiative is
|
||||
Jeremy Stanley (fungi).
|
||||
|
|
@ -0,0 +1,105 @@
|
|||
Designate Contributors
|
||||
======================
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
`Designate`_ is a service that manages DNS Zones and Recordsets. It supports
|
||||
multiple DNS Servers, and DNS Service Providers, making it vital for any
|
||||
network or web-based application.
|
||||
|
||||
They need contributors to help find and fix bugs, develop new features, and
|
||||
help maintain the quality of the project, including cross-project initiatives.
|
||||
Designate is quite stable, with any new features requiring long term planning,
|
||||
design, and phased implementation.
|
||||
|
||||
Designate welcomes everyone, from someone starting in the community to senior
|
||||
contributors who want new, interesting problems to tackle. Contributors will
|
||||
get to work on a project that will be a central part of any OpenStack
|
||||
deployment and work on a project that needs to scale from a small single node
|
||||
install to a system controlling DNS servers worldwide.
|
||||
|
||||
Value
|
||||
-----
|
||||
|
||||
Flexibility
|
||||
~~~~~~~~~~~
|
||||
|
||||
DNS is fundamental in gracefully directing users and applications to services.
|
||||
It allows the flexibility to replace underlying hardware while presenting
|
||||
consumers with a consistent endpoint. Designate provides this flexibility to
|
||||
operators and end users.
|
||||
|
||||
Designate supports a wide range of drivers for various `DNS servers`_ and
|
||||
providers, which allows deployers to integrate Designate into pre-existing
|
||||
DNS infrastructures.
|
||||
|
||||
Self-Service
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Self-serviceability is a core tenet of OpenStack `technical vision`_. Designate
|
||||
helps OpenStack clouds adhere to that principle by exposing DNS functionality
|
||||
directly to end-users. Designate allows cloud operators to delegate the control
|
||||
of DNS zones to end users, to avoid complex ticket based workflows for DNS
|
||||
updates.
|
||||
|
||||
|
||||
User Experience
|
||||
---------------
|
||||
|
||||
When end users are building applications in a cloud native way, relying on
|
||||
external tooling to provision DNS entries adds complexity. With the advancement
|
||||
of IPv6, services required to have DNS entries, to avoid application user
|
||||
confusion.
|
||||
|
||||
Designate adds an important part of the value add for cloud infrastructure,
|
||||
and ensures that OpenStack has feature parity with other cloud providers.
|
||||
|
||||
|
||||
Integrations
|
||||
------------
|
||||
|
||||
Designate integrates with many other tools to allow for zero touch management
|
||||
of DNS Zones and Records. The integration with neutron allows admins to have
|
||||
PTR records (for reverse DNS lookups) managed for Floating IP ranges, without
|
||||
giving direct privileged access to the reverse zone to users.
|
||||
|
||||
Tools like `letsencrypt certbot`_ allow for auto provisioning of SSL certs
|
||||
using DNS-01 validation, while tools like `Heat`_, `Terraform`_ and `Ansible`_
|
||||
allow for the provisioning of DNS Zones and Records to be integrated into
|
||||
pre-existing workflows for applications.
|
||||
|
||||
Kubernetes `external-dns`_ support adds simple annotation based DNS management for
|
||||
applications running in kubernetes clusters with load balancers or ingress
|
||||
support.
|
||||
|
||||
Consistency
|
||||
~~~~~~~~~~~
|
||||
|
||||
The OpenStack community continues to evolve, and this evolution requires large
|
||||
cross-project initiatives. Furthermore, users and operators expect consistency
|
||||
across the OpenStack platform. Examples from recent history include
|
||||
OpenStack-wide support for `Python 3`_ and easing operator pain by moving
|
||||
`policy configuration`_ into code. Ensuring Designate stays up-to-date with
|
||||
these initiatives is imperative in reducing operational costs, complexity, and
|
||||
user frustration.
|
||||
|
||||
Contact
|
||||
-------
|
||||
|
||||
If you are interested, please join #openstack-dns on Freenode or contact the
|
||||
Designate PTL (Graham Hayes - mugsie), the Technical Committee sponsor (TBD).
|
||||
You may also email the openstack discuss mailing list with the tag [designate]
|
||||
in the subject.
|
||||
|
||||
.. _`Designate`: https://governance.openstack.org/tc/reference/projects/designate.html
|
||||
.. _`DNS servers`: https://docs.openstack.org/designate/latest/admin/support-matrix.html
|
||||
.. _`technical vision`: https://governance.openstack.org/tc/reference/technical-vision.html
|
||||
.. _`letsencrypt certbot` : https://pypi.org/project/certbot-dns-openstack/
|
||||
.. _`Heat`: https://docs.openstack.org/heat/rocky/template_guide/openstack.html#OS::Designate::RecordSet
|
||||
.. _`Terraform`: https://www.terraform.io/docs/providers/openstack/r/dns_recordset_v2.html
|
||||
.. _`Ansible`: https://docs.ansible.com/ansible/latest/modules/os_zone_module.html#os-zone-module
|
||||
.. _`external-dns`: https://github.com/kubernetes-incubator/external-dns
|
||||
.. _`Python 3`: https://governance.openstack.org/tc/goals/stein/python3-first.html
|
||||
.. _`policy configuration`: https://governance.openstack.org/tc/goals/queens/policy-in-code.html
|
||||
.. _`list`: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
|
||||
|
|
@ -0,0 +1,66 @@
|
|||
Documentation owners
|
||||
====================
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
The #1 pain point in OpenStack, for contributors and users alike, is
|
||||
complexity. While cutting down complexity everywhere we can is critical;
|
||||
proper documentation is essential in addressing that complexity. It directly
|
||||
benefits operators and users of OpenStack, but also facilitates ramping up new
|
||||
direct contributors to the project itself.
|
||||
|
||||
The documentation team has been struggling with limited resources since the
|
||||
dawn of OpenStack, despite the heroic efforts of previous team members. The
|
||||
community outlined an ambitious `plan`_ to decentralize the Documentation team,
|
||||
turning it into a guidance and mentoring support team. To be successful,
|
||||
project teams need to own their documentation, which means that the role of
|
||||
documentation owners will be critical.
|
||||
|
||||
Volunteers for this role will drive this ambitious transition, by being members
|
||||
of their project team and members of the new decentralized documentation team.
|
||||
On the long-term, they will become a reference go-to person in their project,
|
||||
and respected mentors in the OpenStack community.
|
||||
|
||||
Value
|
||||
-----
|
||||
|
||||
Increased Operational Efficiency
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Documentation naturally disseminates knowledge, but it should also be easy for
|
||||
readers to find what they are looking for. This process reduces bottlenecks on
|
||||
human resources and support by allowing users, operators, and contributors to
|
||||
find answers to questions themselves. Less time spent answering common
|
||||
questions means more time focusing on more complicated requests, maintenance,
|
||||
and code.
|
||||
|
||||
Faster Onboarding
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
Contributors come from all different backgrounds and experiences. As a result,
|
||||
they often share similar questions about high-level concepts or processes used
|
||||
within the OpenStack community or components. Consistently documenting
|
||||
processes enables contributors without requiring them to pull tribal knowledge
|
||||
from an existing developer. This documentation fast-tracks contributors to
|
||||
making productive contributions.
|
||||
|
||||
Consistency
|
||||
~~~~~~~~~~~
|
||||
|
||||
Users, customers, and operators are required to reference a vast pool of
|
||||
documentation spread across multiple repositories and sites. Implementing
|
||||
consistency in wording, format, content, and location provides readers with a
|
||||
first-class experience. Additionally, users build confidence and trust in
|
||||
software when it is well documented.
|
||||
|
||||
Contact
|
||||
-------
|
||||
|
||||
For questions about getting involved with this initiative, reach out to the
|
||||
OpenStack Discuss mailing `list`_. You may also contact the `Documentation`_
|
||||
PTL or the Technical Committee sponsor for this item (dhellmann).
|
||||
|
||||
.. _`plan`: https://review.opendev.org/#/c/472275/
|
||||
.. _`list`: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
|
||||
.. _`Documentation`: https://governance.openstack.org/tc/reference/projects/documentation.html
|
||||
|
|
@ -0,0 +1,48 @@
|
|||
Glance Contributors
|
||||
===================
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
`Glance`_ is a service to manage disk images for OpenStack clouds. It was one
|
||||
of the first projects developed in the OpenStack ecosystem. Nearly every
|
||||
OpenStack deployment contains a Glance service. Without Glance, Nova cannot
|
||||
create servers.
|
||||
|
||||
Glance is looking for new contributors who would be willing to provide reviews,
|
||||
to work on bugs, or to work on new features. Glance has welcomed interns,
|
||||
junior developers, and more senior developers. In every case, it is a great way
|
||||
to grow and contribute to OpenStack.
|
||||
|
||||
Value
|
||||
-----
|
||||
|
||||
Maintenance Costs
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
Glance is a critical service in OpenStack. Contributions to the future of the
|
||||
image registry are essential to the stability of OpenStack. More importantly,
|
||||
Glance is not feature-complete. There is significant technical debt that needs
|
||||
to be taken care of and several features to implement.
|
||||
|
||||
Consistency
|
||||
~~~~~~~~~~~
|
||||
|
||||
The OpenStack community continues to evolve, and this evolution requires large
|
||||
cross-project initiatives. Furthermore, users and operators expect consistency
|
||||
across the OpenStack platform. Examples from recent history include
|
||||
OpenStack-wide support for `Python 3`_ and easing operator pain by moving
|
||||
`policy configuration`_ into code. Ensuring Glance stays up-to-date with these
|
||||
initiatives is imperative in reducing operational costs, complexity, and user
|
||||
frustration.
|
||||
|
||||
Contact
|
||||
-------
|
||||
|
||||
Interested? Join the Glance IRC channel (#openstack-glance) or reach out to the
|
||||
OpenStack discuss `mailing list`_ using the `[glance]` tag.
|
||||
|
||||
.. _`Glance`: https://governance.openstack.org/tc/reference/projects/glance.html
|
||||
.. _`Python 3`: https://governance.openstack.org/tc/goals/stein/python3-first.html
|
||||
.. _`policy configuration`: https://governance.openstack.org/tc/goals/queens/policy-in-code.html
|
||||
.. _`mailing list`: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
|
||||
|
|
@ -0,0 +1,51 @@
|
|||
Goal Champions
|
||||
==============
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
As OpenStack matures, large initiatives linger that affect the community as a
|
||||
whole. Like with any large body of work, someone needs to step up and
|
||||
coordinate the group, keep track of progress, call for and chair regular
|
||||
meetings, and publish status updates. PTLs do this work for project teams,
|
||||
leaders do it for various cross-project working groups and SIGs, and champions
|
||||
do it to help us complete :ref:`release-cycle-goals` over a cycle.
|
||||
Additionally, efficient coordination is one of the most productive ways to get
|
||||
things done, especially in large communities.
|
||||
|
||||
The work of those champions is essential to the success of OpenStack, and yet
|
||||
it is often challenging to find volunteers for those positions. Contributing as
|
||||
a goal champion takes time (several hours per week), and that commitment needs
|
||||
to be properly recognized and celebrated.
|
||||
|
||||
Volunteers for this role will make a direct impact on the productivity of
|
||||
others, become respected leaders in OpenStack community, build influence among
|
||||
their peers, and make great candidates for future elected leadership positions
|
||||
in OpenStack.
|
||||
|
||||
Value
|
||||
-----
|
||||
|
||||
Opportunity for Influence
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
As a sponsor or partial sponsor of a community-wide initiative, you have the
|
||||
opportunity to influence the decision-making process. This influence is
|
||||
particularly true if you have existing workarounds or have attempted
|
||||
alternative solutions, both of which are essential perspectives to have in the
|
||||
goal selection process.
|
||||
|
||||
Early Adoption
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
By sponsoring a community goal champion, you have someone in-house to answer
|
||||
questions about the ongoing work and decision making process upstream. This can
|
||||
be an excellent resource in minimizing disruption to downstream products and
|
||||
services, especially tracking a large piece of work across services and
|
||||
projects.
|
||||
|
||||
Contact
|
||||
-------
|
||||
|
||||
If you are interested in helping with community goals, contact the Technical
|
||||
Committee sponsor for this item (dhellmann).
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
:orphan:
|
||||
|
||||
========================================
|
||||
2018 Upstream Investment Opportunities
|
||||
========================================
|
||||
|
||||
.. note::
|
||||
|
||||
This page links to the items from the previous "Help Most Wanted" list,
|
||||
which are retained here for reference. We are in the process of rewriting
|
||||
these items in the form of upstream investment opportunities for 2019.
|
||||
Please refer to the :doc:`../index` page for the latest information.
|
||||
|
||||
.. toctree::
|
||||
:glob:
|
||||
:maxdepth: 1
|
||||
:titlesonly:
|
||||
|
||||
*
|
||||
|
|
@ -0,0 +1,82 @@
|
|||
Consistent Role Based Access Control
|
||||
====================================
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
OpenStack is comprised of APIs that allow users to manage physical and virtual
|
||||
infrastructure. Contributors wrote these APIs for end users and operators
|
||||
alike. With tenancy being a pillar of OpenStack's technical vision, ensuring
|
||||
isolation between users and layers of the infrastructure is imperative to
|
||||
OpenStack's long-term success.
|
||||
|
||||
The OpenStack project has grown a tremendous amount of functionality over the
|
||||
last several years. Unfortunately, evolution in the way services protect their
|
||||
APIs failed to maintain pace with feature development. As a result, services
|
||||
today do not protect APIs in ways that expose functionality effectively to
|
||||
users, support security requirements, reduce operational complexity for
|
||||
operators, or aid interoperability.
|
||||
|
||||
Since the Pike release, there has been renewed efforts to improve tools and
|
||||
libraries for contributors to use to correct these issues.
|
||||
|
||||
Value
|
||||
-----
|
||||
|
||||
Increased Functionality
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Currently, most OpenStack services have a very binary approach to RBAC
|
||||
enforcement. This approach usually handicaps new functionality from being
|
||||
exposed to users because users typically do not fall in one of two camps.
|
||||
Contributors either need to lock down the feature to only system
|
||||
administrators, or open it up to nearly every user in the deployment. This is
|
||||
especially true for APIs that expose details about multiple tenants.
|
||||
|
||||
Implementing better API protection allows contributors to expose more
|
||||
functionality to end users and operators by default. Lowering the bar for users
|
||||
to access a feature means more opportunities for feedback loops, more end users
|
||||
getting access to the functionality they need, and makes OpenStack more usable
|
||||
overall.
|
||||
|
||||
Enhanced Security
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
OpenStack has a wide variety of users. Auditing APIs and adjusting default
|
||||
access control increases security across the entire OpenStack platform. This
|
||||
exercise gives contributors the ability to provide secure defaults for new
|
||||
deployments. Reasonable default values that are inherently secure makes it
|
||||
easier for organizations with strict security requirement to deploy OpenStack.
|
||||
|
||||
Reduced Operational Complexity
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Today's RBAC enforcement implementation lacks secure defaults, but it is
|
||||
somewhat configurable. Deployments that must have a more secure enforcement
|
||||
implementation are forced to maintain arduously complex configuration files.
|
||||
Furthermore, many organizations re-implement similar use cases.
|
||||
|
||||
Interoperability
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Because policy configuration gives deployments the flexibility to maintain
|
||||
complicated policies at their own expense, it is common to see many
|
||||
organizations solve the same problem. Unfortunately, it's unlikely many of them
|
||||
are sharing the same solution. This pattern impedes interoperability between
|
||||
deployments, making it frustrating for users interacting with different
|
||||
OpenStack clouds.
|
||||
|
||||
Offering a reasonable set of roles and implementing basic RBAC improves
|
||||
interoperability by not requiring each organization to solve the same problem
|
||||
individually.
|
||||
|
||||
Contact
|
||||
-------
|
||||
|
||||
For more information on how to contribute to this initiative, please read the
|
||||
`authorization documentation`_ dedicated to describing the problem.
|
||||
For questions about getting involved with this initiative, reach out to the
|
||||
OpenStack Discuss mailing `list`_.
|
||||
|
||||
.. _authorization documentation: https://docs.openstack.org/keystone/latest/contributor/services.html#why-are-authorization-scopes-important
|
||||
.. _list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
|
||||
|
|
@ -0,0 +1,77 @@
|
|||
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
|
||||
<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss>`_.
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
:orphan:
|
||||
|
||||
========================================
|
||||
2019 Upstream Investment Opportunities
|
||||
========================================
|
||||
|
||||
.. note::
|
||||
|
||||
The latest list of upstream investment opportunities can always be found on
|
||||
the :doc:`../index` page. Historical data is retained for reference.
|
||||
|
||||
.. toctree::
|
||||
:glob:
|
||||
:maxdepth: 1
|
||||
:titlesonly:
|
||||
|
||||
*
|
||||
|
|
@ -0,0 +1 @@
|
|||
../template
|
||||
|
|
@ -0,0 +1,53 @@
|
|||
===================================
|
||||
Upstream Investment Opportunities
|
||||
===================================
|
||||
|
||||
Many companies in the OpenStack community are looking to invest in upstream
|
||||
development of OpenStack, for many reasons: to build expertise within the
|
||||
organisation; to minimise the cost of downstream maintenance by addressing
|
||||
issues at the source; to drive insights gained from serving their customers
|
||||
into the upstream design; to mitigate business risks presented by a `tragedy of
|
||||
the commons`_; or just to support the community. One study has shown that
|
||||
companies that contribute to Open Source projects are able to capture up to
|
||||
twice as much value from their use of the software than those who do not
|
||||
contribute are.\ [#Nagle]_ However, OpenStack is a large project and figuring
|
||||
out where best to invest to derive business value can seem daunting, especially
|
||||
for those new to the community.
|
||||
|
||||
This page presents a curated set of suggested investment areas based on the
|
||||
current opportunities available in the community, along with contact points for
|
||||
each who can help you get started. The list is in no particular order - which
|
||||
opportunity is the best fit depends on the nature of your business. In general,
|
||||
contributors to the community need not be solely devoted to upstream
|
||||
development, but we have found that long-term commitments generate the most
|
||||
value for both the project and the sponsoring organisation.
|
||||
|
||||
Current Investment Opportunities
|
||||
--------------------------------
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
2019/index
|
||||
|
||||
.. note::
|
||||
|
||||
This process is new in 2019. You may wish to refer to the entries from the
|
||||
previous :doc:`Help Most Wanted list <2018/index>` while the process of
|
||||
converting them to the new format is underway.
|
||||
|
||||
Inclusion Criteria
|
||||
------------------
|
||||
|
||||
Only entries approved in the current calendar year are shown, but entries from
|
||||
previous years may be reproposed if they are still relevant. Each item should
|
||||
provide a business case that potential sponsors can use to identify whether the
|
||||
opportunity is relevant to them, a description of the kind of experience needed
|
||||
as well as the mentoring opportunities the community is able to provide, and at
|
||||
least one point of contact for anyone interested in contributing.
|
||||
|
||||
.. _`tragedy of the commons`: https://en.wikipedia.org/wiki/Tragedy_of_the_commons
|
||||
|
||||
.. rubric:: Footnotes
|
||||
|
||||
.. [#Nagle] Nagle, Frank, `Learning by Contributing: Gaining Competitive Advantage Through Contribution to Crowdsourced Public Goods <https://dx.doi.org/10.2139/ssrn.3091831>`_ (December 21, 2017).
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
=================================
|
||||
Investment Opportunity Template
|
||||
=================================
|
||||
|
||||
Summary
|
||||
-------
|
||||
|
||||
Briefly describe the general field in which contributions are sought.
|
||||
|
||||
Business Case
|
||||
-------------
|
||||
|
||||
Describe a business case for investment from the point of view of the
|
||||
organisation paying for the contributions. Readers need a way to identify
|
||||
whether their organisation is one that would benefit from this specific
|
||||
upstream investment, so be sure to include that. The business case should also
|
||||
describe exactly how the investment is expected to save them money, create
|
||||
additional (monetary) value, reduce business risk, or all of the above.
|
||||
|
||||
Technical Details
|
||||
-----------------
|
||||
|
||||
Describe in more detail the nature of the contributions sought, and the
|
||||
prerequisites that candidates attempting to help should begin with. You should
|
||||
also describe the nature and extent of the mentoring that is on offer to
|
||||
anybody who takes the work on.
|
||||
|
||||
Contact
|
||||
-------
|
||||
|
||||
List at least one point of contact to help potential contributors get started.
|
||||
These contacts should be prepared to either act as mentors or find mentors for
|
||||
interested contributors.
|
||||
Loading…
Reference in New Issue