oaktreemodel 0.0.2

Base protobuf data model for oaktree

oaktree is a gRPC interface for interacting with OpenStack clouds that is inherently interoperable and multi-cloud aware.

oaktreemodel is the protobuf definitions and the libraries and/or code generated from that to make it possible for people of all languages to interact with the gRPC system without developing a python dependency anywhere.

At start, go, C++ and python are supported.

With go, the generated files are checked in to the git repo, because that’s how go dependencies work.

With C++ and python, they are not, as we exepct the unit of consumption to be a built library and header files for C++ or a PyPI package for Ruby. It’s the most likely that as we add structure for more languages that they will follow the C++/Python approach and not the go approach - but the decision will be made on a per-language basis and reported back here.

Note on API compat

tl;dr - Upgrading oaktree should NEVER negatively impact end users.

Until a 1.0.0 release is cut, please consider that literally everything in this repo can change with no notice or consideration of breaking backwards compat. This is a new approach to several things and it’s entirely likely we’re going to get things wrong a few times.

Post 1.0.0 oaktree and oaktreemodel will be held to the same backwards-compat promises as shade itself. That is - there will never be backwards-compat breaking release, and it should _always_ be safe to deploy the latest release in production. In fact, even for people running older stable releases of OpenStack, the recommendation will be to run the latest oaktree, so that the latest cross-compatibility changes can be picked up.

Note on Implementations

It is absolutely the intent of oaktreemodel that multiple implementations based on the protobuf descriptions exist for the client interaction. In fact, the code generated and published from this repo is fairly low-leve on a gRPC basis, so it’s almost certainly the case that each language will want to consume this code in the context of some other library that has an end-user focused UI.

It is absolutely NOT the intent that multiple implementations of the server side exist.

The reason for that is that, at least as of now, the business logic in the shade library is extensive and complex. It handles a million corner cases in the underlying clouds. oaktree servers should all be able to talk not just to the cloud they are deployed with, but also to other OpenStack clouds either talking to the remote oaktree or directly to the remote OpenStack API.

The client interfaces in gRPC should be considered to be comprehensive and as descriptive of the interface as possible. For people wanting an oaktree server, please use actual oaktree.

Building

First you need some dependencies:

pip install bindep
apt-get install $(bindep -b)
pip install -f requirements.txt
pip install grpcio-tools
go get -u github.com/golang/protobuf/protoc-gen-go

Then you can build the code:

autoreconf -fi
./configure
make

• Source: http://git.openstack.org/cgit/openstack/oaktreemodel

• Bugs: http://storyboard.openstack.org