Container Infrastructure Management Service for OpenStack
Go to file
Tom Cammann 54f1f7c89f Backport multiple template fixes
Includes backport "deafault external_network to "public""
heat-coe-templates: I03c74f2fb47a33820e0bac4947aeaaf096feade3

Includes backport "do not provide default image names"
Image naming is not standard enough for us to provide defaults.
heat-coe-templates: I67345c3ec807b15101c7248853469c860e0abe8d

Includes backport "minor README updates"
heat-coe-templates: I01270324a2ee31c8fe4369047806634dbbf1cb01

Change-Id: Idc3e27db85f8d06be82cc1c07c62384a4ee13c84
2015-06-15 10:01:14 +00:00
contrib/templates/example Add Template Definitions 2015-04-09 08:47:15 -07:00
devstack Remove old hack for requirements 2015-06-02 09:57:48 +08:00
doc/source Minor improvement of the quickstart guide 2015-06-13 21:36:53 -04:00
etc/magnum introduce policy for magnum 2015-06-02 06:17:22 +08:00
magnum Backport multiple template fixes 2015-06-15 10:01:14 +00:00
specs Remove trailing spaces in container-service.rst 2015-05-07 16:08:35 +08:00
tools Convert to new DevStack plugin model for functional testing 2015-04-02 21:14:20 -04:00
.coveragerc Initial commit from github (squashed) 2014-11-18 09:23:37 -05:00
.gitignore Add coe attribute to BayModel 2015-04-27 21:10:57 -05:00
.gitreview Update .gitreview for project rename 2015-03-28 00:20:40 +00:00
.mailmap Initial commit from github (squashed) 2014-11-18 09:23:37 -05:00
.testr.conf Make room for functional tests 2015-04-02 12:25:43 -04:00
CONTRIBUTING.rst Workflow documentation is now in infra-manual 2014-12-05 03:30:45 +00:00
Dockerfile Fix the docker build image issue 2015-05-18 11:11:25 +08:00
HACKING.rst Correct doc format 2015-02-28 07:06:18 +08:00
LICENSE Initial commit from github (squashed) 2014-11-18 09:23:37 -05:00
MANIFEST.in Copy Ironic's database model codebase 2014-12-02 15:04:31 -07:00
README.rst Update magnum document to use openstack as namespace 2015-03-28 20:14:42 +08:00
babel.cfg Initial commit from github (squashed) 2014-11-18 09:23:37 -05:00
bandit.yaml Add Bandit security lint checking via tox 2015-04-08 10:41:42 -07:00
functional_creds.conf.sample Make functional test work with new tox env 2015-05-19 11:07:34 +08:00
openstack-common.conf cleanup openstack-common.conf and sync updated files 2015-06-10 11:05:54 +00:00
requirements.txt Updated from global requirements 2015-06-11 00:42:50 +00:00
setup.cfg Add Swarm TemplateDefinition 2015-04-17 12:19:27 -07:00
setup.py Sync from oslo requirements 2015-01-14 08:29:17 +08:00
test-requirements-bandit.txt Update bandit for new usage requirement 2015-04-10 11:19:17 +08:00
test-requirements.txt Reorder requirements into ascii-betical order. 2015-05-25 17:13:55 -07:00
tox.ini Fix ignored E121 to E125 pep 8 rules 2015-06-08 10:55:34 +00:00

README.rst

Magnum

new Openstack project for containers.

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