Define 2023 upstream investment opportunities
Copy all three opportunities (QA, Infra and RBAC) from 2022 which I think still need help. Change-Id: Ib76c9b0b74319f039c28c0bba7b5668f47d1ca57
This commit is contained in:
Ghanshyam Mann
parent
b1bb7337fd
commit
28c265e62f
@ -0,0 +1,113 @@
|
||||
==================================
|
||||
Community Infrastructure Sysadmins
|
||||
==================================
|
||||
|
||||
Summary
|
||||
-------
|
||||
|
||||
The OpenStack community is seeking developers and system administrators
|
||||
with a background in maintaining Unix/Linux servers and free software to
|
||||
join the TACT SIG Infrastructure team. This 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.
|
||||
|
||||
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.
|
||||
|
||||
There is a particular need for infrastructure team members from APAC and EMEA.
|
||||
|
||||
Business Case
|
||||
-------------
|
||||
|
||||
Sponsorship of a team member is a way to visibly help build and
|
||||
maintain the development, collaboration, and testing tools used by the
|
||||
third most active open source project in the world without having to
|
||||
donate hardware. Team members interact with contributors across all
|
||||
the OpenStack projects as well as with the OpenStack service providers
|
||||
who supply resources for OpenStack CI systems.
|
||||
|
||||
Sponsors of infrastructure team members have a "seat at the table" as
|
||||
decisions are made about how to improve and scale OpenStack
|
||||
infrastructure going forwards.
|
||||
|
||||
Sponsors gain in-house expertise and experience building large-scale,
|
||||
adaptive software development infrastructure with open-source tools
|
||||
and public configuration management. There is no better way to gain
|
||||
exposure to and expertise with leading-edge CI/CD in advance of
|
||||
potential deployment at home than to place someone on the team
|
||||
deploying one of the world's most scaled out instances of the `Zuul
|
||||
project`_.
|
||||
|
||||
The software developed, skills involved, and open community practices
|
||||
learned can have high value downstream in a sponsors own enterprises
|
||||
and software products.
|
||||
|
||||
.. _`Zuul project`: https://zuul-ci.org
|
||||
|
||||
Technical Details
|
||||
-----------------
|
||||
|
||||
The 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 and gain a deep understanding and visibility
|
||||
within the community is by helping operate this infrastructure.
|
||||
|
||||
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 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
|
||||
~~~~~
|
||||
|
||||
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 or TC IRC channel (``openstack-infra`` on `OFTC
|
||||
<https://www.oftc.net/>`_) or (``openstack-tc`` on `OFTC <https://www.oftc.net/>`_).
|
||||
You can also reach out through the openstack-discuss mail list at list.openstack.org
|
||||
if you would like to get involved.
|
||||
17
reference/upstream-investment-opportunities/2023/index.rst
Normal file
17
reference/upstream-investment-opportunities/2023/index.rst
Normal file
@ -0,0 +1,17 @@
|
||||
:orphan:
|
||||
|
||||
=======================================
|
||||
2023 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,110 @@
|
||||
==================================
|
||||
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. In addition, Tempest
|
||||
is used in the interoperability certification program. 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
|
||||
92
reference/upstream-investment-opportunities/2023/rbac.rst
Normal file
92
reference/upstream-investment-opportunities/2023/rbac.rst
Normal 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/
|
||||
@ -28,7 +28,7 @@ Current Investment Opportunities
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
2022/index
|
||||
2023/index
|
||||
|
||||
Previous Investment Opportunities
|
||||
---------------------------------
|
||||
@ -42,6 +42,7 @@ Previous Investment Opportunities
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
2022/index
|
||||
2021/index
|
||||
2020/index
|
||||
2019/index
|
||||
|
||||
Loading…
Reference in New Issue
Block a user