20a52de7ea
1.What is the problem Originally this patch had been committed to the Tricircle and provided policy control support. After splitting Trio2o needs these functions, too. So we plan to synchronize this patch from Gerrit to Trio2o. You can find the old patch on Gerrit here[1]. Currently Admin-API is to manage pod and pod-binding, the Admin-API access is hard coded, and only admin role is allowed. OpenStack usually use policy.json based authorization to control the API-request. Policy feature is missing in the Trio2o. 2. What is the solution to the problem Remove hard coded Admin-API request authorization, use policy instead. For Nova API-GW and Cinder API-GW, the API access control should be done at bottom OpenStack as far as possible if the API request will be forwarded to bottom OpenStack directly for further processing; only these APIs which only interact with database for example flavor and volume type, because these APIs processing will be terminated at the Trio2o layer, so policy control should be done in Nova API-GW or Cinder API-GW. No work needs to do in Trio2o Neutron Plugin for Neutron API server is there, Neutron API server will be responsible for policy control. 3. What the features need to be implemented to the Trio2o to realize the solution In this patch, default policy option and rule, and policy control in Admin-API were added. Using the default option and value to generate the policy.json will be implemented in next patch. No policy.json is mandatory required after this patch is merged, if no policy.json is configured or provided, the policy control will use the default rule automatically. [1] https://review.openstack.org/#/c/356262/ Change-Id: I61cab299d1286dcc2729dd943f4134c427d79bb1
Trio2o
The Trio2o provides an OpenStack API gateway to allow multiple OpenStack instances, spanning in one site or multiple sites or in hybrid cloud, to be managed as a single OpenStack cloud.
The Trio2o and these managed OpenStack instances will use shared KeyStone (with centralized or distributed deployment) or federated KeyStones for identity management.
The Trio2o presents one big region to the end user in KeyStone. And each OpenStack instance called a pod is a sub-region of the Trio2o in KeyStone, and usually not visible to end user directly.
The Trio2o acts as OpenStack API gateway, can handle OpenStack API calls, schedule one proper OpenStack instance if needed during the API calls handling, forward the API calls to the appropriate OpenStack instance.
The end user can see avaialbility zone(AZ) and use AZ to provision VM, Volume, through the Trio2o. One AZ can include many OpenStack instances, the Trio2o can schedule and bind OpenStack instance for the tenant inside one AZ. A tenant's resources could be bound to multiple specific bottom OpenStack instances in one or multiple AZs automatically.
- Free software: Apache license
- Design documentation: Trio2o Design Blueprint
- Wiki: https://wiki.openstack.org/wiki/trio2o
- Installation with DevStack: https://github.com/openstack/trio2o/blob/master/doc/source/
- Trio2o Admin API documentation: https://github.com/openstack/trio2o/blob/master/doc/source/api_v1.rst
- Source: https://github.com/openstack/trio2o
- Bugs: http://bugs.launchpad.net/trio2o
- Blueprints: https://launchpad.net/trio2o