|
|
| (28 intermediate revisions by 9 users not shown) |
| Line 1: |
Line 1: |
| − | __TOC__
| + | This content has moved to: https://docs.openstack.org/python-openstacksdk/latest/ |
| − | | |
| − | = Summary =
| |
| − | | |
| − | This is a '''proposed''' OpenStack project that is designed to improve the experience of OpenStack end-users by consolidating the various OpenStack python-* client back-ends and common code into a unified, well designed and user focused SDK ("Software Development Toolkit"). | |
| − | | |
| − | '''Detailed Description''':
| |
| − | | |
| − | Currently, OpenStack's end user stories for both command-line and application developer consumers of OpenStack based clouds is confusing, fractured and inconsistent. This means that if a non-operator or OpenStack developer attempts to consume more than a single service from a deployed OpenStack system they face an uphill battle. With at least 22 individual python-* clients to install to build a consuming application, each with different APIs and nuances, it becomes increasingly difficult to consume OpenStack clouds.
| |
| − | | |
| − | The Unified SDK proposes a new project with a single API namespace ("openstack") that would provide users with a single point of entry and series of supporting functions/methods from which to build applications and tools. As a side effect of this consolidation, it becomes very easy to derive a unified CLI, such as openstackclient, or specialized per-service CLI tools. However, it is important that the definition of SDK -- the compilation of the APIs and developer functions -- and CLI tools stay separate as it is easy to conflate the idea of "clients," which is the state we have today.
| |
| − | | |
| − | Once the initial work to create the Unified SDK is complete; the next stage would be to collapse the individual python-* clients and use this as their logical backends.
| |
| − | | |
| − | The project is under active development, and will be moving to the regular OpenStack meeting schedule soon.
| |
| − | | |
| − | '''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.
| |
| − | | |
| − | = Audience =
| |
| − | There are two key audiences for this project:
| |
| − | | |
| − | * '''Application Developers''': 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.
| |
| − | * '''Command line consumers''': These are similar to the Application Developers, as their requirements are to use a consistent, single binary/script to interact with OpenStack Clouds. The commands they use should follow a consistent command line format, terminology and not require a large number of child dependencies to be installed onto the system.
| |
| − | | |
| − | = Resources =
| |
| − | {| border="1" cellpadding="2" cellspacing="0"
| |
| − | | Source code || https://github.com/jnoller/openstacksdk (temporary)
| |
| − | |-
| |
| − | | Bug tracker || https://launchpad.net/unifiedsdk
| |
| − | |-
| |
| − | | Blueprints
| |
| − | |-
| |
| − | | Developer doc
| |
| − | |-
| |
| − | | Etherpad Notes || https://etherpad.openstack.org/p/unified-sdk-notes
| |
| − | |}
| |
| − | :
| |
| − | | |
| − | = Project Outline =
| |
| − | :
| |
| − | == Requirements ==
| |
| − | * Verified mocks/stubs for testing at all layers.
| |
| − | * python-requests based REST client (built as "requests first").
| |
| − | * Minimize external dependencies. This includes inter-openstack-project dependencies.
| |
| − | * Do not dictate a concurrency paradigm. Ensure that the design is sound, but allow users to use gevent/threads/asyncio/etc.
| |
| − | * Ensure thread safety. Avoid the use of and modification of global objects.
| |
| − | * Documentation must be assumption free. The target audience are not intimately familiar with the internals or designs of the services exposed by the SDK.
| |
| − | * Vendors / Hosts of OpenStack clouds should be able to easily layer in or plug into the SDK in order to make necessary changes or customizations, and to easily package and ship without requiring a complete fork of the codebase.
| |
| − | * No "Least Common Denominator". The client (Layer 4) code for keystoneclient might be in openstack.api.auth, but it would be able to be as advanced as it would like from an api standpoint, and whatever subset of functionality could be exposed in higher level abstractions (such as a CLI). Bonus is that horizon could potentially use this work.
| |
| − | | |
| − | == Non-Requirements ("Things Not To Do") ==
| |
| − | * Do not use setuptools / disutils / etc entrypoints for plugs and vendor additions. This prevents single binary builds on windows and other platforms.
| |
| − | * Take code, and ideas from the other python-* clients, but do not wrap them as openstackclient (currently) does.
| |
| − | * Do not mix the CLI implementation with the SDK: the SDK can have helpers for auth caching, auth retries, etc, but should not get involved in the CLI implementation aspect.
| |
| − | :
| |
| − | | |
| − | = IRC =
| |
| − | | |
| − | The developers use IRC in #openstacksdk on freenode for development discussion.
| |
| − | | |
| − | = Meetings =
| |
| − | * The weekly Unified SDK [[Meetings/UnifiedSDK|IRC meeting]] is held on TBD at [http://www.timeanddate.com/worldclock/fixedtime.html?msg=UnifiedSDK+Meeting&iso=20131015T16 1600 UTC.]
| |
| − | * [http://eavesdrop.openstack.org/meetings/sdk_team_meeting/2014/ 2014 Unified SDK Meeting Archive]
| |
| − | :
| |
| − | | |
| − | = Frequently Asked Questions =
| |
| − | Please see our [[UnifiedSDK/FAQ|FAQ]] for answers to common questions about the Unified SDK.
| |
