Introduce 2020 upstream investment opportunities.
This creates the structure and adapts the documentation for the business investment opportunties, to be ready for year 2020. As planned, I did not copy all 2019 opportunities, to allow the opportunity to prune those. I merely copied the ones which are already started and will need further investments. Change-Id: I71f443846d56a9d22834f8683614a40b0eeac00c
This commit is contained in:
Jean-Philippe Evrard
parent
1f9ffc8438
commit
c95fa495ff
@ -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
|
||||
<https://freenode.net>`_) 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
|
||||
17
reference/upstream-investment-opportunities/2020/index.rst
Normal file
17
reference/upstream-investment-opportunities/2020/index.rst
Normal file
@ -0,0 +1,17 @@
|
||||
:orphan:
|
||||
|
||||
========================================
|
||||
2020 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:
|
||||
|
||||
*
|
||||
90
reference/upstream-investment-opportunities/2020/rbac.rst
Normal file
90
reference/upstream-investment-opportunities/2020/rbac.rst
Normal file
@ -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
|
||||
@ -28,13 +28,22 @@ Current Investment Opportunities
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
2019/index
|
||||
2020/index
|
||||
|
||||
Previous Investment Opportunities
|
||||
---------------------------------
|
||||
|
||||
.. 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.
|
||||
The "Investment Opportunities" process was introduced in 2019.
|
||||
The entries before (2018) are following our "Help Most Wanted list" format,
|
||||
which does not highlight business opportunities.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
2019/index
|
||||
2018/index
|
||||
|
||||
Inclusion Criteria
|
||||
------------------
|
||||
|
||||
Loading…
Reference in New Issue
Block a user