Define 2022 upstream investment opportunities

Copy two opportunities (QA and RBAC) from 2021 which I think
still need help.

Change-Id: I0ce59a2d52a30b1a801661c05d1efe4c45017e3b
This commit is contained in:
Ghanshyam Mann 2022-03-24 19:46:35 -05:00 committed by Ghanshyam
parent b640dd8c1c
commit 9ac2102274
4 changed files with 220 additions and 1 deletions

View File

@ -0,0 +1,17 @@
:orphan:
========================================
2022 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:
*

View File

@ -0,0 +1,109 @@
==================================
Quality Assurance Developers
==================================
Summary
-------
The OpenStack community is seeking developers with a background in Python, bash
shell, or Javascript programming and free software to join the OpenStack QA
team. This team is responsible for maintaining and evolving OpenStack's robust
and comprehensive quality assurance tools, which form the backbone of the
OpenStack CI pipeline.
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.
Business Case
-------------
Sponsorship of a team member is a way to visibly help build and maintain the
development and testing tools used by one of the most active open source project
in the world. Team members interact with contributors across all the OpenStack
projects as well as with the OpenStack infrastructure system administrators who
ensure reliable access to resources for OpenStack CI systems.
Sponsors gain in-house expertise and experience building complex, comprehensive,
and modular software testing suites with open-source tools. There is no better
way to gain exposure to and expertise with the testing suites that power a
leading-edge CI/CD in advance of potential deployment at home than to place
someone on the team that creates testing frameworks that are used by dozens of
software projects to run tests in the `Zuul project`_.
The software developed, skills involved, and open community practices learned
can have high value downstream in a sponsor's own enterprises and software
products.
Technical Details
-----------------
The OpenStack QA team is responsible for designing, building and maintaining the
testing harnesses and tools that are used in the day to day development and CI
process of the OpenStack project, as well as production cloud testing also. In
the OpenStack paradigm, project teams are responsible for writing tests that
exercise and validate the code that they are contributing. The definition of
what needs to be tested is standardized in the `Project Testing Interface`_.
The OpenStack QA team writes code that:
* deploys the OpenStack services in a form usable for testing (devstack)
* runs a gauntlet of API tests against the control plane of each OpenStack
service (tempest)
* including complex RBAC operations (patrole),
* OpenStack-health dashboard for visualizing test results of OpenStack CI jobs
* grenade for upgrade testing
* hacking for code style
In addition to being used in the OpenStack CI pipeline, tempest and patrole can
also be used for large scale testing of production clouds. 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 and gain a deep understanding and
visibility within the community is by helping maintain and evolve these tools.
Everything possible goes through code review, and gets extensively documented
and communicated with the rest of the community over IRC and mailing lists.
Value
~~~~~
The OpenStack project is composed of dozens of project teams that focus on
delivering specific services that together compose OpenStack. What defines code
as being part of OpenStack is that it has passed review by the tools built by
the QA team. Contributors to the QA team have a special vantage point, being
able to see how these services fit together, and how those integrations can have
problems. This is first-hand experience with the challenges of integrating a
large, distributed multi-component project, which is a valuable skill.
Experiences with integration challenges with projects of this scale can be
transferred to other large projects within the enterprise.
Innovating On Top Of A Massive Effort
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The culture built around extensive testing in OpenStack makes it easier for us
to trust patches proposed for review. There are many kinds of testing
performed: unit, functional, style, API, scenario, upgrade, and end-to-end
(fullstack) testing are all supported by the toolset developed by the QA team.
For more information, see the `Project Team Guide, Testing Chapter`_.
In addition, we are constantly looking forward to innovate our testing
framework to provide more accurate simulations of customer issues. Duplicating
a social and technical quality control system of this size takes incredible
amounts of time, people, and patience. Bolstering the QA system we already have
in place allows you to focus on testing that is specific to your product or
service while benefitting from the best of breed for testing innovation that
occurs anywhere in the project..
Contact
-------
Join the OpenStack QA IRC channel (``#openstack-qa`` on `OFTC IRC`_), email
the openstack-discuss mailing list at list.openstack.org, or contact the `QA
PTL`_ directly if you would like to get involved.
.. _`Zuul project`: https://zuul-ci.org
.. _`Project Testing Interface`: https://governance.openstack.org/tc/reference/project-testing-interface.html
.. _`Project Team Guide, Testing Chapter`: https://docs.openstack.org/project-team-guide/testing.html
.. _`OFTC IRC`: https://www.oftc.net
.. _`QA PTL`: https://governance.openstack.org/tc/reference/projects/quality-assurance.html

View File

@ -0,0 +1,92 @@
=====================================
Consistent and Secure Policy Defaults
=====================================
Summary
-------
The OpenStack community is seeking contributors to the Secure Policy Defaults
initiative. This ongoing initiative aims to provide set of common roles that
will enable secure enforcement of authorization policies across OpenStack
projects and deployments.
Business Case
-------------
Supporting consistent and secure default RBAC configuration in OpenStack
provides the best means to secure your organization's OpenStack deployment and
to make security maintenance less error-prone. This is especially incumbent upon
organizations that are subject to security audits and strict regulations for
whom OpenStack's lack of consistent RBAC prohibits production use.
Sponsorship of contributors to this RBAC initiative positions them to
influence direction and drive implementation choices on critical
infrastructure used by every OpenStack project and every OpenStack
deployment -- ensuring that an organization's downstream requirements
are fully understood and taken into account.
Because of its use in every OpenStack project, work on this RBAC
initiative is a good way to build reputation and influence upstream,
and at the same time gain vital in-house expertise for an
organization's downstream deployments or software distributions.
Technical Details
-----------------
Currently, most OpenStack services have a very binary approach to Role Based
Access Control (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.
For detail, read the `community-wide rbac goal`_ document.
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
organizations 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
-------
To contribute to this initiative, contact the `champion`_ of this goal or the
`OpenStack Technical Committee`_.
.. _community-wide rbac goal: https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html
.. _champion: https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#champion
.. _OpenStack Technical Committee: https://governance.openstack.org/tc/

View File

@ -28,7 +28,7 @@ Current Investment Opportunities
.. toctree:: .. toctree::
:maxdepth: 2 :maxdepth: 2
2021/index 2022/index
Previous Investment Opportunities Previous Investment Opportunities
--------------------------------- ---------------------------------
@ -42,6 +42,7 @@ Previous Investment Opportunities
.. toctree:: .. toctree::
:maxdepth: 2 :maxdepth: 2
2021/index
2020/index 2020/index
2019/index 2019/index
2018/index 2018/index