x/oaktree
Code Issues Proposed changes
gRPC API Porcelain Layer for OpenStack
6 Commits 1 Branch 0 Tags 137 KiB
Python 78.3%
Shell 20.7%
reStructuredText 1%
9732db18a1
Go to file
Monty Taylor 9732db18a1
Rename Search to List 
Change-Id: I74fca76e90bca61bc41379096d0f3f0410e07ca5
2016-11-14 06:31:21 -06:00
devstack Rename Search to List 2016-11-14 06:31:21 -06:00
doc/source Clean a couple of meaningless things 2016-11-08 16:58:08 -06:00
oaktree Rename Search to List 2016-11-14 06:31:21 -06:00
.coveragerc Initial commit 2016-11-03 07:45:03 -05:00
.gitignore Initial commit 2016-11-03 07:45:03 -05:00
.gitreview Initial commit 2016-11-03 07:45:03 -05:00
.mailmap Initial commit 2016-11-03 07:45:03 -05:00
.testr.conf Initial commit 2016-11-03 07:45:03 -05:00
CONTRIBUTING.rst Add a few more docs 2016-11-08 15:34:23 -06:00
HACKING.rst Initial commit 2016-11-03 07:45:03 -05:00
LICENSE Initial commit 2016-11-03 07:45:03 -05:00
MANIFEST.in Initial commit 2016-11-03 07:45:03 -05:00
README.rst Initial commit 2016-11-03 07:45:03 -05:00
requirements.txt Manual sync with global requirements 2016-11-08 17:47:49 -06:00
setup.cfg Initial commit 2016-11-03 07:45:03 -05:00
setup.py Manual sync with global requirements 2016-11-08 17:47:49 -06:00
test-requirements.txt Manual sync with global requirements 2016-11-08 17:47:49 -06:00
TODO Initial commit 2016-11-03 07:45:03 -05:00
tox.ini Clean a couple of meaningless things 2016-11-08 16:58:08 -06:00

README.rst

oaktree

Make your cloud throw some shade

oaktree is a gRPC interface for interacting with OpenStack clouds that is inherently interoperable and multi-cloud aware. It is based on the python shade library, which grew all of the logic needed to interact with OpenStack clouds and to work around differences in vendor deployment choices. Rather than keep all of that love in Python Library form, oaktree allows othre languages to reap the benefits as well.

oaktree is not a replacement for all of the individual project REST APIs. Those are all essential for cross-project communication and are well suited for operators who can be expected to know things about how they have deployed their clouds - and who in fact WANT to be able to make changes in the cloud knowing deployment specifics. oaktree will never be for them.

oaktree is for end-users who do not and should not know what hypervisor, what storage driver or what network stack the deployer has chosen. The two sets of people are different audiences, so oaktree is a project to support the end user.

Using

Install oaktreemodel by hand. Then:

In one window:

python oaktree/server.py

oaktree/server.py assumes you have a clouds.yaml accessible.

In another window:

python -i devstack/test.py

You'll have an images and a flavors object you can poke at.

If you want to operate against a different cloud than devstack, you can pass it to devstack/test.py as the first command line argument.

Shape of the Project

oaktree should be super simple to deploy, and completely safe for deployers to upgrade from master constantly. Once it's released as a 1.0, it should NEVER EVER EVER EVER EVER EVER EVER have a backwards incompatible change. There is no reason, no justification, no obessession important enough to inflict such pain on the user.

The shade library will grow the ability to detect if a cloud has an oaktree api available, and if it does, it will use it. Hopefully we'll quickly reach a point where all deployers are deploying oaktree.