OpenStack-SDK-PHP

Note: This SDK is currently being developed. It's not ready to be used in application development as the API will be changing.

Summary

This is a proposed OpenStack project that is designed to improve the experience of OpenStack end-users who are using the PHP programming language by providing them with everything they need to develop applications against OpenStack.

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.

An overview of the contribution process is available.

Audience

The primary target for this package is application developers who develop against OpenStack. This does not include those who develop OpenStack itself or operate it. 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.

Other target audiences, a good distance away in priority, are those who develop the SDK and those who wish to extent the SDK.

Requirements

1. Feel native to developers working in PHP.
2. Support multiple API versions for each service (e.g., Nova API v1 and v2).
3. Provide a method for vendor extensions. Numerous vendors have extensions. There needs to be a method to support these to aid the end developer.
4. PHP SDK Use Cases
5. There is NO requirement to maintain backwards compatibility with any existing SDK.

Short Term Roadmap

1. Migrate to a structure to support multiple service API versions. [blueprint]
2. Move to use Guzzle 4 for the default transport layer and proposed FIG PSR for HTTP Messages. [blueprint] (completed)
3. Update documentation to phpdoc. [blueprint] (completed)
4. Having a high level service discovery mechanism similar to what projects like the openstackclient are doing. [blueprint]
5. Mechanism for vendor extensions. [blueprint]
6. Evaluate the user json schema and magic methods to describe the method calls and APIs. [blueprint]
7. Add more user facing documentation. [blueprint]
8. Add more services.

Todo

1. Evaluate Guzzle 4 services and json schema.

Design Decisions

1. PHP 5.4 is the minimum supported version of PHP.
2. The entire PHP SDK will be in one project. A project for each service isn't something we can easily do on the OpenStack infrastructure.
3. Vendor extensions will have a different top level namespace rather than be inside the OpenStack namespace. This will allow them to easily live as separate projects that depend on the OpenStack project (via composer). If vendor extensions can be part of the OpenStack PHP SDK they could be easily moved in.

Resources

Source code	https://github.com/stackforge/openstack-sdk-php
Bug tracker	https://bugs.launchpad.net/openstack-sdk-php
Blueprints	https://blueprints.launchpad.net/openstack-sdk-php
Etherpad	https://etherpad.openstack.org/p/php-sdk
Gerrit Reviews	https://review.openstack.org/#/q/status:open+project:stackforge/openstack-sdk-php,n,z

IRC

The developers use IRC in #openstack-sdks on freenode for development discussion.