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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
