e8a77b6e1b
Now the magnum.common.policy just support an "enforce" method to wsgi policy check. And this "enforce" method should be inline the body of wsgi method. Such as: from magnum.common import policy class BaysController(rest.RestController): .... @wsme_pecan.wsexpose(None, types.uuid_or_name, status_code=204) def delete(self, bay_ident): ... doc string ... policy.enforce(pecan.request.context, "bay:create") .... common stuff .... This inline style is ugly. Now this patch is improving it. This patch uses a decorator for policy check. With this decorator we can do the policy check as follow: from magnum.common import policy class BaysController(rest.RestController): .... @policy.enforce_wsgi("bay", "delete") @wsme_pecan.wsexpose(None, types.uuid_or_name, status_code=204) def delete(self, bay_ident): ... Here: This decorator MUST appear first (the outermost decorator) on an API method for it to work correctly. The decorator use functools.wraps to decorator the wsgi function. A common decorator(without functools.wraps) replaces the original function with an new one, that means it will lose the information about the original function, it would be a serious problem for pcen wsgi. That's why we have functools.wraps. This takes a function used in a decorator and adds the functionality of copying over the function name, docstring, arguments list, etc. ref: http://stackoverflow.com/questions/308999/what-does-functools-wraps-do Co-Authored-By: yuntongjin <yuntong.jin@intel.com> Change-Id: I9a7baf9559ff924ca4e261db2961b9d3c8763325 Partial-implements: blueprint policy-enforce |
||
---|---|---|
contrib/templates/example | ||
devstack | ||
doc/source | ||
etc/magnum | ||
magnum | ||
specs | ||
tools | ||
.coveragerc | ||
.gitignore | ||
.gitreview | ||
.mailmap | ||
.testr.conf | ||
CONTRIBUTING.rst | ||
Dockerfile | ||
HACKING.rst | ||
LICENSE | ||
MANIFEST.in | ||
README.rst | ||
babel.cfg | ||
bandit.yaml | ||
functional_creds.conf.sample | ||
openstack-common.conf | ||
requirements.txt | ||
setup.cfg | ||
setup.py | ||
test-requirements-bandit.txt | ||
test-requirements.txt | ||
tox.ini |
README.rst
Magnum
new Openstack project for containers.
- Free software: Apache license
- Documentation: http://docs.openstack.org/developer/magnum
- Source: http://git.openstack.org/cgit/openstack/magnum
- Bugs: http://bugs.launchpad.net/magnum
- ReST Client: http://git.openstack.org/cgit/openstack/python-magnumclient
Architecture
There are seven different types of objects in the Magnum system:
- Bay: A collection of node objects where work is scheduled
- BayModel: An object stores template information about the bay which is used to create new bays consistently
- Node: A baremetal or virtual machine where work executes
- Pod: A collection of containers running on one physical or virtual machine
- Service: An abstraction which defines a logical set of pods and a policy by which to access them
- ReplicationController: An abstraction for managing a group of PODs to ensure a specified number of PODs are running
- Container: A docker container
Two binaries work together to compose the Magnum system. The first binary accessed by the python-magnumclient code is the magnum-api ReST server. The ReST server may run as one process or multiple processes. When a ReST request is sent to the client API, the request is sent via AMQP to the magnum-conductor process. The ReST server is horizontally scalable. At this time, the conductor is limited to one process, but we intend to add horizontal scalability to the conductor as well.
The magnum-conductor process runs on a controller machine and connects to a kubernetes or docker ReST API endpoint. The kubernetes and docker ReST API endpoints are managed by the bay object.
When service or pod objects are created, Kubernetes is directly contacted via the k8s ReST API. When container objects are acted upon, the docker ReST API is directly contacted.
Features
- Abstractions for bays, containers, nodes, pods, and services
- Integration with Kubernetes and Docker for backend container technology.
- Integration with Keystone for multi-tenant security.
- Integration with Neutron for k8s multi-tenancy network security.
Installation and Usage
- Getting Started Guides: http://git.openstack.org/cgit/openstack/magnum/tree/doc/source/dev/dev-quickstart.rst