diff --git a/reference/upstream-investment-opportunities/2021/goal-champions.rst b/reference/upstream-investment-opportunities/2021/goal-champions.rst new file mode 100644 index 000000000..7450bbfa7 --- /dev/null +++ b/reference/upstream-investment-opportunities/2021/goal-champions.rst @@ -0,0 +1,66 @@ +============== +Goal Champions +============== + +Summary +------- + +The OpenStack community is seeking coordinators for +the work to fulfill our :ref:`release-cycle-goals`. + +Business Case +------------- + +Organizations who sponsor Goal Champions +have someone in-house who understands the upstream decision making and +implementation work across services and projects. This in-house +expertise can help minimize disruption to downstream products and +services and help position timely communications and expectations with +regard to upcoming changes. + +Sponsors of Goal Champions are well-positioned to influence +decision-making not only the implementation choices meeting +community-wide initiatives, but also to help drive the choice and +rollout of upstream goals and use this influence to ensure that one's +own downstream products or deployments remain vital and targeted to +real use cases. + +Sponsorship of a Goal Champion is a good way for an organisation to +demonstrate leadership across the whole of OpenStack, make a direct +impact on the productivity of other contributors, and build +influence among peers. Goal Champions make great candidates for +future elected leadership positions in OpenStack. + + +.. _`backlog of potential goals`: https://etherpad.openstack.org/p/community-goals + +Technical Details +----------------- + +Each release series, the OpenStack Technical Committee selects a set +of shared objectives to be fulfilled in that release cycle, that +provide value across Openstack projects by e.g. advancing consistency +and user experience across OpenStack or addressing shared technical +debt. These goals are selected from a `backlog of potential goals`_ +based on feedback from deployers, users, contributors, and PTLs and +goal discussion during Forum events. + +PTLs are responsible for ensuring that the work required to meet a +goal is completed within their own projects, but Goal Champions are +needed to guide, coordinate and track the work across projects. A +Goal Champion needs a general understanding of the technical issues +involved in a goal, but primarily needs to communicate, track +progress, foster shared understanding across projects, and help remove +impediments. + +Contact +------- + +If possible, attend Forum and Summit sessions on series goals and +offer to sponsor a champion for a goal as part of the discussions at +these. After these face to face events, discussion of goals continues +on the Technical Committee IRC channel (``#openstack-tc`` on `Freenode +`_) and on the OpenStack-discuss `mailing list`_ +using the ``[goals]`` tag in the subject line. + +.. _`mailing list`: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss diff --git a/reference/upstream-investment-opportunities/2021/index.rst b/reference/upstream-investment-opportunities/2021/index.rst new file mode 100644 index 000000000..ce6ba9b76 --- /dev/null +++ b/reference/upstream-investment-opportunities/2021/index.rst @@ -0,0 +1,17 @@ +:orphan: + +======================================== + 2021 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: + + * diff --git a/reference/upstream-investment-opportunities/2021/quality-assurance-developers.rst b/reference/upstream-investment-opportunities/2021/quality-assurance-developers.rst new file mode 100644 index 000000000..b4f113fa5 --- /dev/null +++ b/reference/upstream-investment-opportunities/2021/quality-assurance-developers.rst @@ -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 `Freenode 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 +.. _`Freenode IRC`: https://freenode.net +.. _`QA PTL`: https://governance.openstack.org/tc/reference/projects/quality-assurance.html diff --git a/reference/upstream-investment-opportunities/2021/rbac.rst b/reference/upstream-investment-opportunities/2021/rbac.rst new file mode 100644 index 000000000..4538bb0fc --- /dev/null +++ b/reference/upstream-investment-opportunities/2021/rbac.rst @@ -0,0 +1,90 @@ +===================================== +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. + +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, join the `Secure Default Policies Popup +Team`_. Read the `popup team wiki page`_ for references on how to contribute and +how to communicate with the team. + +.. _Secure Default Policies Popup Team: https://governance.openstack.org/tc/reference/popup-teams.html#secure-default-policies +.. _popup team wiki page: https://wiki.openstack.org/wiki/Consistent_and_Secure_Default_Policies_Popup_Team diff --git a/reference/upstream-investment-opportunities/index.rst b/reference/upstream-investment-opportunities/index.rst index bd25e6ed3..d1a8f7689 100644 --- a/reference/upstream-investment-opportunities/index.rst +++ b/reference/upstream-investment-opportunities/index.rst @@ -28,7 +28,7 @@ Current Investment Opportunities .. toctree:: :maxdepth: 2 - 2020/index + 2021/index Previous Investment Opportunities --------------------------------- @@ -42,6 +42,7 @@ Previous Investment Opportunities .. toctree:: :maxdepth: 2 + 2020/index 2019/index 2018/index