Move technical-guidance.rst under technical-guides
We have new directory technical-guides which include the new guidlines unified limits. We can move the existing file technical-guidance.rst also under the same dir to avoid any confusion. Change-Id: Ibe9facc4518b1f1317579373b40a5e63f89d2240
This commit is contained in:
parent
0e28af9708
commit
ba41eb0c7a
@ -1 +1,2 @@
|
|||||||
redirectmatch 301 ^/project-team-guide/project-setup.html$ /project-team-guide/technical-guidance.html
|
redirectmatch 301 ^/project-team-guide/project-setup.html$ /project-team-guide/technical-guidance.html
|
||||||
|
redirectmatch 301 ^/project-team-guide/technical-guidance.html$ /project-team-guide/technical-guides/index.html
|
||||||
|
@ -27,7 +27,6 @@ Contents:
|
|||||||
bugs
|
bugs
|
||||||
vulnerability-management
|
vulnerability-management
|
||||||
dependency-management
|
dependency-management
|
||||||
technical-guidance
|
|
||||||
testing
|
testing
|
||||||
oslo
|
oslo
|
||||||
documentation
|
documentation
|
||||||
|
@ -1,47 +1,6 @@
|
|||||||
=========================================
|
================================
|
||||||
Technical Guidance for OpenStack projects
|
|
||||||
=========================================
|
|
||||||
|
|
||||||
This chapter contains basic technical guidelines to help you design and set
|
|
||||||
up an OpenStack project.
|
|
||||||
|
|
||||||
This content is aspirational, and not prescriptive - while working towards a
|
|
||||||
universally consistent technical design is laudable, it is often impractical,
|
|
||||||
given technical debt, architectural decisions, and project constraints.
|
|
||||||
|
|
||||||
|
|
||||||
Base services
|
|
||||||
-------------
|
|
||||||
|
|
||||||
OpenStack services rely on external services to deliver their functionality.
|
|
||||||
Base services are external services that OpenStack components can assume
|
|
||||||
will be present in any OpenStack deployment. OpenStack components may
|
|
||||||
therefore leverage advanced features exposed by those base services without
|
|
||||||
needing to reimplement the wheel locally.
|
|
||||||
|
|
||||||
The Technical Committee maintains the `list of base services`_.
|
|
||||||
|
|
||||||
The Technical Committee constantly considers new additions to the list,
|
|
||||||
conservatively weighing the benefit of that service against the additional
|
|
||||||
operational cost for OpenStack deployers.
|
|
||||||
|
|
||||||
.. _list of base services: https://governance.openstack.org/tc/reference/base-services.html
|
|
||||||
|
|
||||||
|
|
||||||
API guidelines
|
|
||||||
--------------
|
|
||||||
|
|
||||||
We strive to improve the experience of API end users by converging the
|
|
||||||
OpenStack API to a consistent and pragmatic RESTful design. The
|
|
||||||
`API SIG`_ maintains a `set of API guidelines`_ to that effect.
|
|
||||||
|
|
||||||
.. _API SIG: http://specs.openstack.org/openstack/api-wg
|
|
||||||
|
|
||||||
.. _set of API guidelines: http://specs.openstack.org/openstack/api-wg/#guidelines
|
|
||||||
|
|
||||||
|
|
||||||
Best practices for project setup
|
Best practices for project setup
|
||||||
--------------------------------
|
================================
|
||||||
|
|
||||||
OpenStack has many projects, so many that contributor usability is a
|
OpenStack has many projects, so many that contributor usability is a
|
||||||
serious concern. The harder it is to get from a fresh source tree to a
|
serious concern. The harder it is to get from a fresh source tree to a
|
||||||
@ -49,14 +8,13 @@ contribution, the more difficult it becomes to develop a complex,
|
|||||||
multi-service feature. A consistent project setup reduces this friction, both
|
multi-service feature. A consistent project setup reduces this friction, both
|
||||||
for new contributors and for seasoned ones.
|
for new contributors and for seasoned ones.
|
||||||
|
|
||||||
This section addresses common tools, libraries, and approaches, used in the
|
This document addresses common tools, libraries, and approaches, used in the
|
||||||
OpenStack ecosystem. It begins where the `Consistent Testing Interface`_
|
OpenStack ecosystem. It begins where the `Consistent Testing Interface`_
|
||||||
ends, by explaining guidelines, best practices, lessons learned, and answers
|
ends, by explaining guidelines, best practices, lessons learned, and answers
|
||||||
to frequently asked questions.
|
to frequently asked questions.
|
||||||
|
|
||||||
|
|
||||||
Avoid multi-language projects
|
Avoid multi-language projects
|
||||||
=============================
|
-----------------------------
|
||||||
Every programming language has established solid, reliable tooling for
|
Every programming language has established solid, reliable tooling for
|
||||||
itself, based on assumptions that are relevant only to itself. These
|
itself, based on assumptions that are relevant only to itself. These
|
||||||
assumptions rarely translate well between different languages, and thus any
|
assumptions rarely translate well between different languages, and thus any
|
||||||
@ -76,7 +34,7 @@ project, while providing documentation that explains how these projects are
|
|||||||
integrated.
|
integrated.
|
||||||
|
|
||||||
Subscribe to Global Dependencies
|
Subscribe to Global Dependencies
|
||||||
================================
|
--------------------------------
|
||||||
OpenStack maintains a list of global dependencies, and their version
|
OpenStack maintains a list of global dependencies, and their version
|
||||||
constraints, in order to ensure that peer libraries operate as expected. This
|
constraints, in order to ensure that peer libraries operate as expected. This
|
||||||
is done in an as-needed basis: If your project declares that it is dependent
|
is done in an as-needed basis: If your project declares that it is dependent
|
||||||
@ -85,7 +43,7 @@ particular library is updated. This also permits us to globally freeze our
|
|||||||
dependencies in anticipation of a release.
|
dependencies in anticipation of a release.
|
||||||
|
|
||||||
Follow language-specific Guides
|
Follow language-specific Guides
|
||||||
===============================
|
-------------------------------
|
||||||
|
|
||||||
For a guide for a specific language, please choose the appropriate article
|
For a guide for a specific language, please choose the appropriate article
|
||||||
below.
|
below.
|
||||||
@ -93,7 +51,7 @@ below.
|
|||||||
.. toctree::
|
.. toctree::
|
||||||
:maxdepth: 1
|
:maxdepth: 1
|
||||||
|
|
||||||
Python<project-setup/python>
|
Python<../project-setup/python>
|
||||||
JavaScript<project-setup/javascript>
|
JavaScript<../project-setup/javascript>
|
||||||
|
|
||||||
.. _Consistent Testing Interface: https://governance.openstack.org/tc/reference/project-testing-interface.html
|
.. _Consistent Testing Interface: https://governance.openstack.org/tc/reference/project-testing-interface.html
|
@ -2,7 +2,52 @@
|
|||||||
Technical Guides
|
Technical Guides
|
||||||
================
|
================
|
||||||
|
|
||||||
|
This chapter contains basic technical guidelines to help you design and set
|
||||||
|
up an OpenStack project.
|
||||||
|
|
||||||
|
This content is aspirational, and not prescriptive - while working towards a
|
||||||
|
universally consistent technical design is laudable, it is often impractical,
|
||||||
|
given technical debt, architectural decisions, and project constraints.
|
||||||
|
|
||||||
|
Using Unified Limits
|
||||||
|
--------------------
|
||||||
.. toctree::
|
.. toctree::
|
||||||
:maxdepth: 2
|
:maxdepth: 2
|
||||||
|
|
||||||
unified-limits
|
unified-limits
|
||||||
|
|
||||||
|
Base services
|
||||||
|
-------------
|
||||||
|
|
||||||
|
OpenStack services rely on external services to deliver their functionality.
|
||||||
|
Base services are external services that OpenStack components can assume
|
||||||
|
will be present in any OpenStack deployment. OpenStack components may
|
||||||
|
therefore leverage advanced features exposed by those base services without
|
||||||
|
needing to reimplement the wheel locally.
|
||||||
|
|
||||||
|
The Technical Committee maintains the `list of base services`_.
|
||||||
|
|
||||||
|
The Technical Committee constantly considers new additions to the list,
|
||||||
|
conservatively weighing the benefit of that service against the additional
|
||||||
|
operational cost for OpenStack deployers.
|
||||||
|
|
||||||
|
.. _list of base services: https://governance.openstack.org/tc/reference/base-services.html
|
||||||
|
|
||||||
|
|
||||||
|
API guidelines
|
||||||
|
--------------
|
||||||
|
|
||||||
|
We strive to improve the experience of API end users by converging the
|
||||||
|
OpenStack API to a consistent and pragmatic RESTful design. The
|
||||||
|
`API SIG`_ maintains a `set of API guidelines`_ to that effect.
|
||||||
|
|
||||||
|
.. _API SIG: http://specs.openstack.org/openstack/api-wg
|
||||||
|
|
||||||
|
.. _set of API guidelines: http://specs.openstack.org/openstack/api-wg/#guidelines
|
||||||
|
|
||||||
|
Best practices for project setup
|
||||||
|
--------------------------------
|
||||||
|
.. toctree::
|
||||||
|
:maxdepth: 2
|
||||||
|
|
||||||
|
best-practices-for-project-setup
|
||||||
|
Loading…
Reference in New Issue
Block a user