Open Stack

The golang-client/openstack-sdk-go is an SDK written in Go to operate
against OpenStack REST APIs. The project sits in stackforge and in one
of a number of Go clients for OpenStack. This email is here to
describe what we're doing and some base design decisions.

First, if there are Go clients for OpenStack why is there another
effort in Stackforge? The existing clients don't meet all the
requirements and there are a number of cases where they fall short.
For example, none of the existing clients support multiple REST API
versions. They were written against the versions for a particular
stack. We need an SDK that handles this cleanly.

Ideally, we'd like to pull in working code from existing projects
where the license will allow us to do so.

Some tentative decisions (speak now if you don't agree).

When it comes to directory/package structure we'd use something
similar to the way python does it. That is a directory for each
service (e.g., identity, compute, etc) with another directory in there
for each version. This way we can handle versions like identity v2,
v3, and v4 at the same time.

Since Go is statically typed it would be useful to have a common
interface for base service operations. For example, compute instances
need to be created, destroyed, restarted, and a handful of other
service. Each API version would/should implement some of these base
operations, though in different ways. An interface that implements
these would be useful for applications that use the SDK.

The transport client would be pluggable and dependency injected but
have a same default. It would likely be the built in system to go.
But, we need flexibility here. For example, an application may
communicate with a public cloud through a proxy while communicating
with a private cloud compute endpoint bypassing the proxy. The
flexibility to implement that needs to be in place. This means
managers for service will be needed in packages so the same manager
can be instantiated twice with different transport layers.

The Python SDK is using an ORB style for working with services. This
isn't something we've seen happen much in Go. Instead we're looking at
the manager/resource style setup to be in a manner more common to the
language.

As I said earlier, where ever we can re-use code from existing
projects we'd like to try and do so. Some places there is flexibility
to do some. Some other places licenses (such at the GPLv3) will limit
code reuse and we're going to pay attention to that.

If you have any comments, questions, or want to get involved please jump in.

- Matt