SDK-Development/PythonOpenStackSDK - Revision history

Mordred at 12:12, 26 February 2018

2018-02-26T12:12:58Z

Mordred: Replaced content with "{{#externalredirect: https://docs.openstack.org/python-openstacksdk/latest/}}"

2018-02-26T12:12:40Z

Replaced content with "{{#externalredirect: https://docs.openstack.org/python-openstacksdk/latest/}}"

Andrea-frittoli: /* Resources */

2016-02-17T13:13:55Z

‎Resources

Fabien LD: /* Resources */ Fixing links (users vs contributors)

2015-03-30T11:43:47Z

‎Resources: Fixing links (users vs contributors)

Mzoorikh: /* Detailed Description */

2015-02-19T19:40:25Z

‎Detailed Description

Brian.curtin at 21:24, 13 February 2015

2015-02-13T21:24:13Z

Brian.curtin: /* Summary */

2015-02-13T21:22:48Z

‎Summary

Brian.curtin at 21:21, 13 February 2015

2015-02-13T21:21:37Z

Brian.curtin at 21:18, 13 February 2015

2015-02-13T21:18:55Z

Brian.curtin at 21:16, 13 February 2015

2015-02-13T21:16:53Z

← Older revision		Revision as of 12:12, 26 February 2018
Line 1:		Line 1:
−	~~{{#externalredirect~~: https://docs.openstack.org/python-openstacksdk/latest/}}	+	This content has moved to: https://docs.openstack.org/python-openstacksdk/latest/

← Older revision		Revision as of 12:12, 26 February 2018
Line 1:		Line 1:
−	~~__TOC__~~	+	{{#externalredirect: https://docs.openstack.org/python-openstacksdk/latest/}}
−
−	~~= Summary =~~
−
−	The OpenStack SDK is an project to improve the overall experience of users of OpenStack clouds, from application developers to operators, by providing one place to work with OpenStack's many services. As a a software development kit, the project aims to offer a complete set of libraries to work with OpenStack services, as well as complete documentation and examples for working with the ecosystem.
−
−	~~=== Detailed Description ===~~
−
−	Currently, OpenStack's user stories for both command-line and application developer consumers of OpenStack based clouds is confusing, fractured, and inconsistent. If a consumer who is not "in the know" - read: not an operator or developer involved in creation of OpenStack - attempts to consume more than one service, their complexity increases almost linearly. With each service currently providing its own client, which includes both the library and a command line tool, the number of dependencies along with the varying interfaces used by them offers a less than welcoming experience.
−
−	The python-openstacksdk project is an attempt at providing one place for consumers of OpenStack clouds to look for their interactions. It aims to provide a clean and consistent interface to write Python code that works with any service that your OpenStack cloud provides. Given that it will provide one entry point for working with OpenStack, it then becomes easier for tools to build on top of, such as command line tools, including OpenStackClient.
−
−	~~=== What's in an SDK? ===~~
−
−	~~The root of a complete SDK is a consumer focused set of libraries for interacting with the system. It additionally includes:~~
−	* Documentation aimed at users consuming OpenStack clouds, whether internally at their company or commercially available
−	* Documentation aimed at OpenStack developers, enabling them to extend libraries or contribute their own libraries, including extensions
−	* Examples of usage, including fully functional applications that demo the various services the SDK works with
−
−	~~= Audience =~~
−	~~There are two key audiences for this project:~~
−
−	* Application Developers: Application developers are consumers of OpenStack clouds. While they can be operators or contributors to the services themselves, the primary application developer persona is anyone wanting to develop an application to leverage one or more services provided by OpenStack. These developers require a consistent set of usable APIs with minimal dependencies to manage.
−	* Command line Users: These are similar to the Application Developers, as their requirements include a consistent set of interactions but they're carried out through a single executable that communicates with their OpenStack cloud. As with Application Developers, minimal dependencies to complete their tasks is of high importance.
−
−	Important to both audiences is that terminology is jargon free and doesn't use nicknames or require knowledge of project history or internals. For example, working with the compute service should be done through library or command line interactions utilizing the compute name, not Nova.
−
−	~~= Resources =~~
−	{~~\| border="1" cellpadding="2" cellspacing="0"~~
−	~~\| Source code \|\| https://github.com/openstack/python-openstacksdk~~
−	\|-
−	~~\| Bug tracker \|\| https~~:~~//launchpad.net/python-openstacksdk~~
−	\|-
−	~~\| Blueprints \|\|~~ https://~~launchpad.net/python-openstacksdk~~
−	\|-
−	~~\| User Documentation \|\| http://developer~~.openstack.org~~/sdks~~/python~~/openstacksdk/users/index.html~~
−	\|-
−	~~\| Contributor Documentation \|\| http://developer.openstack.org/sdks/python/~~openstacksdk/~~contributors~~/~~index.html~~
−	\|}
−	:
−
−	~~= 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.
−	* Jargon free. APIs should go by program names ("compute", "storage", "messaging"), rather than the project names ("nova", "swift", "marconi") to ensure the library is accessible to people without significant OpenStack familiarity.
−	* 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.
−
−	~~= IRC =~~
−	~~The developers use IRC in #openstack-sdks on freenode for development discussion.~~
−
−	~~= Meetings =~~
−	* The weekly Python-OpenStackSDK [[Meetings/PythonOpenStackSDK\|IRC meeting]] is held at 1900 UTC in #openstack-meeting-3
−	* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/ 2014 python-openstacksdk Meeting Archive]
−	* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2015/ 2015 python-openstacksdk Meeting Archive]
−
−	~~= Frequently Asked Questions =~~
−	~~Please see our [[PythonOpenStackSDK/FAQ\|FAQ]] for answers to common questions about the Python OpenStack SDK.~~

@@ Line 28: / Line 28: @@
 = Resources =
 {| border="1" cellpadding="2" cellspacing="0"
-|  Source code   || https://github.com/stackforge/python-openstacksdk
+|  Source code   || https://github.com/openstack/python-openstacksdk
 |-
 |  Bug tracker  || https://launchpad.net/python-openstacksdk
@@ Line 34: / Line 34: @@
 |  Blueprints || https://launchpad.net/python-openstacksdk
 |-
-|  User Documentation || http://python-openstacksdk.readthedocs.org/en/latest/users/index.html
+|  User Documentation || http://developer.openstack.org/sdks/python/openstacksdk/users/index.html
 |-
-|  Contributor Documentation || http://python-openstacksdk.readthedocs.org/en/latest/contributors/index.html
+|  Contributor Documentation || http://developer.openstack.org/sdks/python/openstacksdk/contributors/index.html
 |}
+:

@@ Line 34: / Line 34: @@
 |  Blueprints || https://launchpad.net/python-openstacksdk
 |-
-|  User Documentation || http://python-openstacksdk.readthedocs.org/en/latest/contributors/index.html
+|  User Documentation || http://python-openstacksdk.readthedocs.org/en/latest/users/index.html
 |-
-|  Contributor Documentation || http://python-openstacksdk.readthedocs.org/en/latest/users/index.html
+|  Contributor Documentation || http://python-openstacksdk.readthedocs.org/en/latest/contributors/index.html
 |}
+:

@@ Line 9: / Line 9: @@
 Currently, OpenStack's user stories for both command-line and application developer consumers of OpenStack based clouds is confusing, fractured, and inconsistent. If a consumer who is not "in the know" - read: not an operator or developer involved in creation of OpenStack - attempts to consume more than one service, their complexity increases almost linearly. With each service currently providing its own client, which includes both the library and a command line tool, the number of dependencies along with the varying interfaces used by them offers a less than welcoming experience.
-The python-openstacksdk project is an attempt at providing once place for consumers of OpenStack clouds to look for their interactions. It aims to provide a clean and consistent interface to write Python code that works with with any service that your OpenStack cloud provides. Given that it will provide one entry point for working with OpenStack, it then becomes easier for tools to build on top of, such as command line tools, including OpenStackClient.
+The python-openstacksdk project is an attempt at providing one place for consumers of OpenStack clouds to look for their interactions. It aims to provide a clean and consistent interface to write Python code that works with any service that your OpenStack cloud provides. Given that it will provide one entry point for working with OpenStack, it then becomes easier for tools to build on top of, such as command line tools, including OpenStackClient.
 === What's in an SDK? ===

@@ Line 5: / Line 5: @@
 The OpenStack SDK is an project to improve the overall experience of users of OpenStack clouds, from application developers to operators, by providing one place to work with OpenStack's many services. As a a software development kit, the project aims to offer a complete set of libraries to work with OpenStack services, as well as complete documentation and examples for working with the ecosystem.
-== Detailed Description ==
+=== Detailed Description ===
 Currently, OpenStack's user stories for both command-line and application developer consumers of OpenStack based clouds is confusing, fractured, and inconsistent. If a consumer who is not "in the know" - read: not an operator or developer involved in creation of OpenStack - attempts to consume more than one service, their complexity increases almost linearly. With each service currently providing its own client, which includes both the library and a command line tool, the number of dependencies along with the varying interfaces used by them offers a less than welcoming experience.
@@ Line 11: / Line 11: @@
 The python-openstacksdk project is an attempt at providing once place for consumers of OpenStack clouds to look for their interactions. It aims to provide a clean and consistent interface to write Python code that works with with any service that your OpenStack cloud provides. Given that it will provide one entry point for working with OpenStack, it then becomes easier for tools to build on top of, such as command line tools, including OpenStackClient.
-== What's in an SDK? ==
+=== What's in an SDK? ===
 The root of a complete SDK is a consumer focused set of libraries for interacting with the system. It additionally includes:
@@ Line 21: / Line 21: @@
 There are two key audiences for this project:
-* '''Application Developers''': Application developers are consumers of OpenStack clouds. While they can be operators or contributors to the services themselves, the primary application developer persona is anyone wanting to develop an application to leverage one or more services provided by OpenStack. These developers require a consistent set of usable APIs with minimal dependencies to manage.
+* Application Developers: Application developers are consumers of OpenStack clouds. While they can be operators or contributors to the services themselves, the primary application developer persona is anyone wanting to develop an application to leverage one or more services provided by OpenStack. These developers require a consistent set of usable APIs with minimal dependencies to manage.
-* '''Command line consumers''': These are similar to the Application Developers, as their requirements include a consistent set of interactions but they're carried out through a single executable that communicates with their OpenStack cloud. As with Application Developers, minimal dependencies to complete their tasks is of high importance.
+* Command line Users: These are similar to the Application Developers, as their requirements include a consistent set of interactions but they're carried out through a single executable that communicates with their OpenStack cloud. As with Application Developers, minimal dependencies to complete their tasks is of high importance.
 Important to both audiences is that terminology is jargon free and doesn't use nicknames or require knowledge of project history or internals. For example, working with the compute service should be done through library or command line interactions utilizing the compute name, not Nova.
@@ Line 41: / Line 41: @@
 = Project Outline =
-−
-== Requirements ==
+=== Requirements ===
 * Verified mocks/stubs for testing at all layers.
 * python-requests based REST client (built as "requests first").

@@ Line 52: / Line 52: @@
 * 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.
 = IRC =
@@ Line 63: / Line 59: @@
 * The weekly Python-OpenStackSDK [[Meetings/PythonOpenStackSDK|IRC meeting]] is held at 1900 UTC in #openstack-meeting-3
 * [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/ 2014 python-openstacksdk Meeting Archive]
-* [http://eavesdrop.openstack.org/meetings/python_openstack_sdk/2014/ 2014 python-openstacksdk Accidental Archive]
+* [http://eavesdrop.openstack.org/meetings/python_openstacksdk/2015/ 2015 python-openstacksdk Meeting Archive]
 = Frequently Asked Questions =
 Please see our [[PythonOpenStackSDK/FAQ|FAQ]] for answers to common questions about the Python OpenStack SDK.

@@ Line 13: / Line 13: @@
 '''What's in an SDK?''':
-An SDK is more than just a set of APIs. A complete SDK provides a consumer focused set of libraries for interacting with the system, and additionally includes:
+The root of a complete SDK is a consumer focused set of libraries for interacting with the system. It additionally includes:
 * Documentation aimed at users consuming OpenStack clouds, whether internally at their company or commercially available
 * Documentation aimed at OpenStack developers, enabling them to extend libraries or contribute their own libraries, including extensions
@@ Line 21: / Line 21: @@
 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.
+* '''Application Developers''': Application developers are consumers of OpenStack clouds. While they can be operators or contributors to the services themselves, the primary application developer persona is anyone wanting to develop an application to leverage one or more services provided by OpenStack. These developers require a consistent set of usable APIs with minimal dependencies to manage.
-* '''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.
+* '''Command line consumers''': These are similar to the Application Developers, as their requirements include a consistent set of interactions but they're carried out through a single executable that communicates with their OpenStack cloud. As with Application Developers, minimal dependencies to complete their tasks is of high importance.
 = Resources =