Jump to: navigation, search

Difference between revisions of "SDK-Development"

(SDK Projects)
(Add link to SDKs page)
 
(2 intermediate revisions by 2 users not shown)
Line 18: Line 18:
 
== Goals for each SDK ==
 
== Goals for each SDK ==
  
 +
# Don't break clients!
 
# Support multiple API versions for each service (e.g., Keystone API v2 and v3).
 
# Support multiple API versions for each service (e.g., Keystone API v2 and v3).
 
# Use application developer friendly language in descriptions (e.g., Compute instead of Nova).
 
# Use application developer friendly language in descriptions (e.g., Compute instead of Nova).
Line 36: Line 37:
 
==SDK Projects==
 
==SDK Projects==
 
# [[SDK-Development/PythonOpenStackSDK]]
 
# [[SDK-Development/PythonOpenStackSDK]]
 +
# [[SDKs|Full SDK list]]
 
# [[OpenStack-SDK-PHP]]
 
# [[OpenStack-SDK-PHP]]
 
# [[OpenStack-SDK-Ruby]]
 
# [[OpenStack-SDK-Ruby]]
 
# [[OpenStack-SDK-DotNet]]
 
# [[OpenStack-SDK-DotNet]]
 
# [[OpenStack-SDK-Java]]
 
# [[OpenStack-SDK-Java]]
 +
# [[OpenStack-SDK-Node.js]]
  
 
== Resources ==  
 
== Resources ==  

Latest revision as of 10:59, 28 November 2019

To enable application developers to build applications that use OpenStack, we need SDKs for each programming language (e.g., PHP, Go, Java) to provide them with what they need.

The purpose of this page is to work through how we go about building SDKs in a semi-consistent manner on the OpenStack infrastructure.

What's in an SDK?

An SDK is more than just a set of APIs provided to you. A complete SDK provides a consumer focused API for interacting with the system, and it additionally includes:

  • Documentation aimed at users consuming the SDK and system.
  • Clear examples of usage, including functioning, executable examples.
  • The SDK may optionally include tools to help developers use the SDK, such as IDE plugins or batch scripts.

Audience

Application developers build applications that interact with OpenStack. Application developers are not OpenStack Operators or Developers. These are developers looking to consume a feature-rich OpenStack Cloud with its many services. These Developers require a consistent, single namespace API ("Application Programming Interface") that allows them to build and deploy their application with minimal dependencies.

Goals for each SDK

  1. Don't break clients!
  2. Support multiple API versions for each service (e.g., Keystone API v2 and v3).
  3. Use application developer friendly language in descriptions (e.g., Compute instead of Nova).
  4. Provide a manner to extend the services in the SDKs.
  5. Be written in a manner consistent with the language and platform they are for (e.g., A Java SDK shouldn't look like Python).
  6. Contain example code to get started.
  7. Contain documentation explaining how to get started and going with the SDKs and the services.
  8. Contain cross-linked class/module reference documentation.
  9. Contain a release history/change log documenting deprecations, new additions and bug fixes in the SDK (with links wherever possible).
  10. Handle OpenStack extensions in a graceful manner (e.g. you should be able to simply make a method call to determine if an OpenStack cloud supports a particular extension).
  11. Be open source and sustainable.
  12. Open source license must be compatible with Apache License v2?

Non-Goals for each SDK

  1. While an SDK should provide working code examples showing usage of the SDK, it must not provide a complete end-user client (e.g. a CLI) implementation. Such an implementation belongs to a separate project that would depend on and use the appropriate SDK.

SDK Projects

  1. SDK-Development/PythonOpenStackSDK
  2. Full SDK list
  3. OpenStack-SDK-PHP
  4. OpenStack-SDK-Ruby
  5. OpenStack-SDK-DotNet
  6. OpenStack-SDK-Java
  7. OpenStack-SDK-Node.js

Resources

Summit Design Sessions

  1. SDK Documentation Discussion at Grizzly Summit
  2. Documenting Application Developer Resources at Icehouse Summit

Example uses of an SDK

  • Syncing objects between containers from two different providers. For example, syncing objects between a private and public cloud.
  • Using object storage as a back end to store data or files within an application.
  • Building a custom services management tool (e.g., a special purpose CLI or console).