summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJenkins <jenkins@review.openstack.org>2017-09-21 16:41:18 +0000
committerGerrit Code Review <review@openstack.org>2017-09-21 16:41:18 +0000
commit697b7dc3003c5b105f20981fcecea4240f28c247 (patch)
tree511ed463218eae1e24dd1626054980a1d447caf9
parent200e122d3017be4c535e736f2d30bc2c8f397080 (diff)
parent090ee277c20feab6b63506251dc939a57e9920e9 (diff)
Merge "Explain, simply, why extensions are bad"
-rw-r--r--guidelines/extensions.rst23
1 files changed, 17 insertions, 6 deletions
diff --git a/guidelines/extensions.rst b/guidelines/extensions.rst
index 4574dc3..fac14ca 100644
--- a/guidelines/extensions.rst
+++ b/guidelines/extensions.rst
@@ -5,15 +5,26 @@ API Extensions
5 5
6This topic document serves to provide guidance on the topic of API extensions. 6This topic document serves to provide guidance on the topic of API extensions.
7 7
8See also the topic document on :ref:`discoverability`. 8See also the topic documents on :ref:`discoverability` and
9:ref:`interoperability`.
9 10
10Guidance 11Guidance
11-------- 12--------
12 13
13**TODO** Add patches that give a history of current usage of API extensions in 14API extensions are sometimes used to add custom functionality to single
14OpenStack projects. 15deployments of OpenStack. They are not recommended, because when they are
16used, they break interoperability between that cloud and other OpenStack
17deployments.
15 18
16**TODO** Add patches that list the issues with API extensions. 19If a deployment requires custom behaviors over an HTTP API it should be
20implemented in a service separate from the existing OpenStack services.
17 21
18**TODO** Add a patch that makes a proposal about whether or not to recommend 22Those projects that support different functionality based on the presence
19use of API extensions. 23of drivers should strive to contain those differences to the values (not keys)
24in representation objects. Having different URLs in a service, based on
25different drivers, breaks interoperability. Where such functionality is
26absolutely required then it is critical that the functionality be discoverable
27via a capabilities API.
28
29.. note:: At this time the standards and best practices for capabilities
30 discovery are undefined.