libcloud-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [5/5] git commit: docs: Add FAQ page.
Date Wed, 07 Aug 2013 22:13:38 GMT
docs: Add FAQ page.


Branch: refs/heads/trunk
Commit: 90606400727a2c9bcf37adaa31ea445947f0d767
Parents: 1f86a7b
Author: Tomaz Muraus <>
Authored: Wed Aug 7 23:35:35 2013 +0200
Committer: Tomaz Muraus <>
Committed: Wed Aug 7 23:54:59 2013 +0200

 docs/developer_information.rst |  4 ++++
 docs/faq.rst                   | 48 +++++++++++++++++++++++++++++++++++++
 docs/index.rst                 |  1 +
 3 files changed, 53 insertions(+)
diff --git a/docs/developer_information.rst b/docs/developer_information.rst
index 1f8337f..bb3add5 100644
--- a/docs/developer_information.rst
+++ b/docs/developer_information.rst
@@ -1,6 +1,8 @@
 Developer Information
+.. _mailing-lists:
 Mailing Lists
@@ -21,6 +23,8 @@ Archive of old incubator mailing lists:
 * `incubator-libcloud`_
 * `incubator-libcloud-commits`_
+.. _issue-tracker:
 Issue Tracker
diff --git a/docs/faq.rst b/docs/faq.rst
new file mode 100644
index 0000000..09b6c37
--- /dev/null
+++ b/docs/faq.rst
@@ -0,0 +1,48 @@
+Frequently Asked Questions (FAQ)
+Why are the block storage related management methods located in the compute API?
+Block storage related management methods are located in the compute API because
+in most cases block storage API is tightly coupled with the compute API meaning
+that you can't manage block storage independent of the compute API.
+This also makes sense because in most cases you are only interested in attaching
+or detaching volumes from and to the compute nodes.
+I want do add a new provider driver what should I do?
+For now the best thing to do is to look at an existing driver and test cases
+for examples.
+Libcloud currently supports more than 25 different providers. This means we
+have a broad range of examples of different APIs and authentication methods.
+APIs range from simple JSON based REST APIs to SOAP APIs. Authentication
+methods range from simple shared token and digest auth to HMAC signed requests.
+I want to add / propose a new API, what should I do?
+We are always open to accepting a now top level API as long as it matches the
+following criteria:
+1. API must be indented to manage an online infrastructure oriented Cloud
+   service
+2. Similar service is offered by multiple providers
+3. It's possible to build a common API on top of services provided by different
+   services
+Last point is the most important one, because Libcloud acts as a lowest common
+denominator and can be used with many different providers.
+Sometimes it doesn't make sense to build a common Libcloud API even if multiple
+providers offer a similar service. Usually the case is that the APIs are vastly
+different and there aren't enough common points which would allow us to build a
+cross-provider API which would still provide enough benefit to the end user.
+If the API matches the criteria mentioned above you should send a proposal to
+our :ref:`mailing list <mailing-list>` where we can discuss it further. Ideally proposal
should also
+contain a prototype of a driver for at least two different providers. This
+help with making sure that API you designed is not biased against a single
diff --git a/docs/index.rst b/docs/index.rst
index fc87cc2..913f6c0 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -44,6 +44,7 @@ Documentation
+    faq
 .. _`Apache 2.0 license`:

View raw message