x/gantt
Code Issues Proposed changes

Merge to latest. Change ^^^ to ~~~ for third-level headings, change volumes to storage, include ephemeral and swift (TODO).

Browse Source
This commit is contained in:
Todd Willey
2010-10-28 17:21:07 -04:00
parent 3faebd55fd 55ed16dbb0
commit ab509f1ce7
8 changed files with 292 additions and 102 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
doc/source/architecture.rst
View File

@@ -1,6 +1,6 @@
..
Copyright 2010 United States Government as represented by the
Administrator of the National Aeronautics and Space Administration.
Administrator of the National Aeronautics and Space Administration.
All Rights Reserved.
Licensed under the Apache License, Version 2.0 (the "License"); you may
@@ -30,14 +30,16 @@ Below you will find a helpful explanation.
::
[ User Manager ] ---- ( LDAP )
|
| / [ Storage ] - ( ATAoE )
[ API server ] -> [ Cloud ] < AMQP >
| \ [ Nodes ] - ( libvirt/kvm )
< HTTP >
|
[ S3 ]
[ Auth Manager ] ---- ( LDAP )
|
|
|
| / [ Storage ] - ( ATAoE/iSCSI )
[ Web Dashboard ] -> [ nova-api ] < AMQP > -
| \ [ Nodes ] - ( libvirt/kvm )
< HTTP >
|
[ nova-objectstore ]
* API: receives http requests from boto, converts commands to/from API format, and sending requests to cloud controller

82
doc/source/auth.rst
View File

@@ -1,6 +1,6 @@
..
Copyright 2010 United States Government as represented by the
Administrator of the National Aeronautics and Space Administration.
Administrator of the National Aeronautics and Space Administration.
All Rights Reserved.
Licensed under the Apache License, Version 2.0 (the "License"); you may
@@ -15,6 +15,8 @@
License for the specific language governing permissions and limitations
under the License.
.. _auth:
Authentication and Authorization Development Guide
==================================================
@@ -41,7 +43,7 @@ Roles-Based Access Control of AWS-style APIs using SAML Assertions
“Achieving FIPS 199 Moderate certification of a hybrid cloud environment using CloudAudit and declarative C.I.A. classifications”
Introduction
--------------
------------
We will investigate one method for integrating an AWS-style API with US eAuthentication-compatible federated authentication systems, to achieve access controls and limits based on traditional operational roles.
Additionally, we will look at how combining this approach, with an implementation of the CloudAudit APIs, will allow us to achieve a certification under FIPS 199 Moderate classification for a hybrid cloud environment.
@@ -56,59 +58,62 @@ Typical implementations of US eAuth authentication systems are structured as fol
[ SUN Identity Manager or other SAML Policy Controller ]
--> maps URLs to groups…
[ Apache Policy Agent in front of eAuth-secured Web Application ]
In more ideal implementations, the remainder of the application-specific account information is stored either in extended schema on the LDAP server itself, via the use of a translucent LDAP proxy, or in an independent datastore keyed off of the UID provided via SAML assertion.
Basic AWS API call structure
----------------------------
.. _auth_roles:
AWS API calls are traditionally secured via Access and Secret Keys, which are used to sign API calls, along with traditional timestamps to prevent replay attacks. The APIs can be logically grouped into sets that align with five typical roles:
Roles
-----
* System User
* System Administrator
AWS API calls are traditionally secured via Access and Secret Keys, which are used to sign API calls, along with traditional timestamps to prevent replay attacks. The APIs can be logically grouped into sets that align with five typical roles:
* Base User
* System Administrator/Developer (currently have the same permissions)
* Network Administrator
* Project Manager
* Cloud Administrator
* (IT-Sec?)
* Cloud Administrator/IT-Security (currently have the same permissions)
There is an additional, conceptual end-user that may or may not have API access:
There is an additional, conceptual end-user that may or may not have API access:
* (EXTERNAL) End-user / Third-party User
* (EXTERNAL) End-user / Third-party User
Basic operations are available to any System User:
Basic operations are available to any :
* Launch Instance
* Terminate Instance (their own)
* Create keypair
* Delete keypair
* Create, Upload, Delete: Buckets and Keys (Object Store) – their own
* Create, Attach, Delete Volume (Block Store) – their own
* Describe Instances
* Describe Images
* Describe Volumes
* Describe Keypairs
* Create Keypair
* Delete Keypair
* Create, Upload, Delete: Buckets and Keys (Object Store)
System Administrators:
System Administrators/Developers/Project Manager:
* Create, Attach, Delete Volume (Block Store)
* Launch, Reboot, Terminate Instance
* Register/Unregister Machine Image (project-wide)
* Change Machine Image properties (public / private)
* Request / Review CloudAudit Scans
Network Administrator:
* Change Firewall Rules, define Security Groups
* Allocate, Associate, Deassociate Public IP addresses
Project Manager:
* Launch and Terminate Instances (project-wide)
* CRUD of Object and Block store (project-wide)
* Add and remove other users (currently no api)
* Set roles (currently no api)
Cloud Administrator:
Network Administrator:
* Register / Unregister Kernel and Ramdisk Images
* Register / Unregister Machine Image (any)
* Change Machine Image properties (public / private)
* Change Firewall Rules, define Security Groups
* Allocate, Associate, Deassociate Public IP addresses
Cloud Administrator/IT-Security:
* All permissions
Enhancements
------------
* SAML Token passing
* SAML Token passing
* REST interfaces
* SOAP interfaces
@@ -126,7 +131,7 @@ CloudAudit queries may spawn long-running processes (similar to launching instan
RBAC of CloudAudit API calls is critical, since detailed system information is a system vulnerability.
Type declarations
---------------------
-----------------
* Data declarations – Volumes and Objects
* System declarations – Instances
@@ -153,7 +158,7 @@ Dirty Cloud – Hybrid Data Centers
* CloudAudit bridge interfaces
* Anything in the ARP table
A hybrid cloud environment provides dedicated, potentially co-located physical hardware with a network interconnect to the project or users’ cloud virtual network.
A hybrid cloud environment provides dedicated, potentially co-located physical hardware with a network interconnect to the project or users’ cloud virtual network.
This interconnect is typically a bridged VPN connection. Any machines that can be bridged into a hybrid environment in this fashion (at Layer 2) must implement a minimum version of the CloudAudit spec, such that they can be queried to provide a complete picture of the IT-sec runtime environment.
@@ -169,7 +174,7 @@ The Details
System limits
-------------
The following limits need to be defined and enforced:
The following limits need to be defined and enforced:
* Total number of instances allowed (user / project)
* Total number of instances, per instance type (user / project)
@@ -237,4 +242,11 @@ The :mod:`access_unittest` Module
:undoc-members:
:show-inheritance:
The :mod:`ec2` Module
---------------------
.. automodule:: nova.api.ec2
:members:
:undoc-members:
:show-inheritance:

51
doc/source/binaries.rst
View File

@@ -1,6 +1,6 @@
..
Copyright 2010 United States Government as represented by the
Administrator of the National Aeronautics and Space Administration.
Administrator of the National Aeronautics and Space Administration.
All Rights Reserved.
Licensed under the Apache License, Version 2.0 (the "License"); you may
@@ -18,14 +18,43 @@
Nova Binaries
===============
* nova-api
* nova-compute
* nova-manage
* nova-objectstore
* nova-volume
The configuration of these binaries relies on "flagfiles" using the google
gflags package::
The configuration of these binaries relies on "flagfiles" using the google
gflags package. If present, the nova.conf file will be used as the flagfile
- otherwise, it must be specified on the command line::
$ python node_worker.py --flagfile flagfile
$ nova-xxxxx --flagfile flagfile
The binaries can all run on the same machine or be spread out amongst multiple boxes in a large deployment.
nova-manage
-----------
Nova manage is a command line utility to administer the system. It will autmatically try to load a flagfile from /etc/nova/nova-manage.conf to save you having to type it. Info on the commands can be found :ref:`here <manage_usage>`.
nova-api
--------
Nova api receives xml requests and sends them to the rest of the system. It is a wsgi app that routes and authenticate requests. It supports the ec2 and openstack apis.
nova-objectstore
----------------
Nova objectstore is an ultra simple file-based storage system for images that replicates most of the S3 Api. It will soon be replaced with glance and a simple image manager.
nova-compute
------------
Nova compute is responsible for managing virtual machines. It loads a Service object which exposes the public methods on ComputeManager via rpc.
nova-volume
-----------
Nova volume is responsible for managing attachable block storage devices. It loads a Service object which exposes the public methods on VolumeManager via rpc.
nova-network
------------
Nova network is responsible for managing floating and fixed ips, dhcp, bridging and vlans. It loads a Service object which exposes the public methods on one of the subclasses of NetworkManager. Different networking strategies are as simple as changing the network_manager flag::
$ nova-network --network_manager=nova.network.manager.FlatManager
IMPORTANT: Make sure that you also set the network_manager on nova-api and nova_compute, since make some calls to network manager in process instead of through rpc. More information on the interactions between services, managers, and drivers can be found :ref:`here <service_manager_driver>`

180
doc/source/concepts.and.introduction.rst
View File

@@ -1,6 +1,6 @@
..
Copyright 2010 United States Government as represented by the
Administrator of the National Aeronautics and Space Administration.
Administrator of the National Aeronautics and Space Administration.
All Rights Reserved.
Licensed under the Apache License, Version 2.0 (the "License"); you may
@@ -61,27 +61,46 @@ Concept: Virtualization
* qemu
Concept: Instances
------------------
An 'instance' is a word for a virtual machine that runs inside the cloud.
Concept: Storage
----------------
* Ephemeral
* Volumes
* Swift
Volumes
~~~~~~~
A 'volume' is a detachable block storage device. You can think of it as a usb hard drive. It can only be attached to one instance at a time, and it behaves
Ephemeral
~~~~~~~~~
::
TODO(vish): document
Swift
~~~~~
::
TODO(vish): document
Concept: Quotas
---------------
* Defaults
* Override for project
Nova supports per-project quotas. There are currently quotas for number of instances, total number of cores, number of volumes, total number of gigabytes, and number of floating ips.
Concept: RBAC
-------------
* Intersecting Roles
* cloudadmin vs. user admin flag
Nova provides roles based access control (RBAC) for access to api commands. A user can have a number of different :ref:`roles <auth_roles>`. Roles define which api_commands a user can perform.
It is important to know that there are user-specific (sometimes called global) roles and project-specific roles. A user's actual permissions in a particular project are the INTERSECTION of his user-specific roles and is project-specific roles.
For example: A user can access api commands allowed to the netadmin role (like allocate_address) only if he has the user-specific netadmin role AND the project-specific netadmin role.
More information about RBAC can be found in the :ref:`auth`.
Concept: API
------------
@@ -93,16 +112,31 @@ Concept: API
Concept: Networking
-------------------
::
Nova has a concept of Fixed Ips and Floating ips. Fixed ips are assigned to an instance on creation and stay the same until the instance is explicitly terminated. Floating ips are ip addresses that can be dynamically associated with an instance. This address can be disassociated and associated with another instance at any time.
* VLAN
* Cloudpipe
* Certificates (See also: CA)
* Flat Networking
* Flat with DHCP
* How to generate addresses
* Floating Addresses
There are multiple strategies available for implementing fixed ips:
Flat Mode
~~~~~~~~~
The simplest networking mode. Each instance receives a fixed ip from the pool. All instances are attached to the same bridge (br100) by default. The bridge must be configured manually. The networking configuration is injected into the instance before it is booted. Note that this currently only works on linux-style systems that keep networking configuration in /etc/network/interfaces.
Flat DHCP Mode
~~~~~~~~~~~~~~
This is similar to the flat mode, in that all instances are attached to the same bridge. In this mode nova does a bit more configuration, it will attempt to bridge into an ethernet device (eth0 by default). It will also run dnsmasq as a dhcpserver listening on this bridge. Instances receive their fixed ips by doing a dhcpdiscover.
VLAN DHCP Mode
~~~~~~~~~~~~~~
This is the default networking mode and supports the most features. For multiple machine installation, it requires a switch that supports host-managed vlan tagging. In this mode, nova will create a vlan and bridge for each project. The project gets a range of private ips that are only accessible from inside the vlan. In order for a user to access the instances in their project, a special vpn instance (code name cloudpipe) needs to be created. Nova generates a certificate and key for the userto access the vpn and starts the vpn automatically.
The following diagram illustrates how the communication that occurs between the vlan (the dashed box) and the public internet (represented by the two clouds)
.. image:: /images/cloudpipe.png
:width: 100%
..
Concept: Services
-----------------
@@ -115,10 +149,122 @@ Concept: Services
* nova-instancemonitor
.. _manage_usage:
Concept: nova-manage
--------------------
nova manage
Introduction
~~~~~~~~~~~~
The nova-manage command is used to perform many essential functions for
administration and ongoing maintenance of nova, such as user creation,
vpn management, and much more.
The standard pattern for executing a nova-manage command is:
``nova-manage <command> <subcommand> [<args>]``
For example, to obtain a list of all projects:
``nova-manage project list``
User Maintenance
~~~~~~~~~~~~~~~~
* user admin: creates a new admin and prints exports
* arguments: name [access] [secret]
* user create: creates a new user and prints exports
* arguments: name [access] [secret]
* user delete: deletes an existing user
* arguments: name
* user exports: prints access and secrets for user in export format
* arguments: name
* user list: lists all users
* arguments: none
* user modify: update a users keys & admin flag
* arguments: accesskey secretkey admin
* leave any field blank to ignore it, admin should be 'T', 'F', or blank
Project Maintenance
~~~~~~~~~~~~~~~~~~~
* project add: Adds user to project
* arguments: project user
* project create: Creates a new project
* arguments: name project_manager [description]
* project delete: Deletes an existing project
* arguments: project_id
* project environment: Exports environment variables to an sourcable file
* arguments: project_id user_id [filename='novarc]
* project list: lists all projects
* arguments: none
* project quota: Set or display quotas for project
* arguments: project_id [key] [value]
* project remove: Removes user from project
* arguments: project user
* project scrub: Deletes data associated with project
* arguments: project
* project zipfile: Exports credentials for project to a zip file
* arguments: project_id user_id [filename='nova.zip]
User Role Management
~~~~~~~~~~~~~~~~~~~~
* role add: adds role to user
* if project is specified, adds project specific role
* arguments: user, role [project]
* role has: checks to see if user has role
* if project is specified, returns True if user has
the global role and the project role
* arguments: user, role [project]
* role remove: removes role from user
* if project is specified, removes project specific role
* arguments: user, role [project]
Nova Shell
~~~~~~~~~~
* shell bpython
* start a new bpython shell
* shell ipython
* start a new ipython shell
* shell python
* start a new python shell
* shell run
* ???
* shell script: Runs the script from the specifed path with flags set properly.
* arguments: path
VPN Management
~~~~~~~~~~~~~~
* vpn list: Print a listing of the VPNs for all projects.
* arguments: none
* vpn run: Start the VPN for a given project.
* arguments: project
* vpn spawn: Run all VPNs.
* arguments: none
Floating IP Management
~~~~~~~~~~~~~~~~~~~~~~
* floating create: Creates floating ips for host by range
* arguments: host ip_range
* floating delete: Deletes floating ips by range
* arguments: range
* floating list: Prints a listing of all floating ips
* arguments: none
Network Management
~~~~~~~~~~~~~~~~~~
* network create: Creates fixed ips for host by range
* arguments: [fixed_range=FLAG], [num_networks=FLAG],
[network_size=FLAG], [vlan_start=FLAG],
[vpn_start=FLAG]
Concept: Flags

2
doc/source/conf.py
View File

@@ -16,7 +16,7 @@ import sys, os
# If extensions (or modules to document with autodoc) are in another directory,
# add these directories to sys.path here. If the directory is relative to the
# documentation root, use os.path.abspath to make it absolute, like shown here.
sys.path.insert(0, '../..')
sys.path.insert(0, os.path.abspath('../../'))
# -- General configuration -----------------------------------------------------

BIN
doc/source/images/cloudpipe.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 88 KiB

34
doc/source/network.rst
View File

@@ -1,6 +1,6 @@
..
Copyright 2010 United States Government as represented by the
Administrator of the National Aeronautics and Space Administration.
Administrator of the National Aeronautics and Space Administration.
All Rights Reserved.
Licensed under the Apache License, Version 2.0 (the "License"); you may
@@ -52,65 +52,65 @@ Components
----------
There are several key components:
* NetworkController (Manages address and vlan allocation)
* NetworkController (Manages address and vlan allocation)
* RoutingNode (NATs public IPs to private IPs, and enforces firewall rules)
* AddressingNode (runs DHCP services for private networks)
* BridgingNode (a subclass of the basic nova ComputeNode)
* TunnelingNode (provides VPN connectivity)
Component Diagram
-----------------
Overview::
(PUBLIC INTERNET)
(PUBLIC INTERNET)
| \
/ \ / \
[RoutingNode] ... [RN] [TunnelingNode] ... [TN]
| \ / | |
| < AMQP > | |
[AddressingNode]-- (VLAN) ... | (VLAN)... (VLAN) --- [AddressingNode]
[AddressingNode]-- (VLAN) ... | (VLAN)... (VLAN) --- [AddressingNode]
\ | \ /
/ \ / \ / \ / \
[BridgingNode] ... [BridgingNode]
[NetworkController] ... [NetworkController]
\ /
< AMQP >
|
/ \
[CloudController]...[CloudController]
[CloudController]...[CloudController]
While this diagram may not make this entirely clear, nodes and controllers communicate exclusively across the message bus (AMQP, currently).
While this diagram may not make this entirely clear, nodes and controllers communicate exclusively across the message bus (AMQP, currently).
State Model
-----------
Network State consists of the following facts:
* VLAN assignment (to a project)
* Private Subnet assignment (to a security group) in a VLAN
* Private Subnet assignment (to a security group) in a VLAN
* Private IP assignments (to running instances)
* Public IP allocations (to a project)
* Public IP associations (to a private IP / running instance)
While copies of this state exist in many places (expressed in IPTables rule chains, DHCP hosts files, etc), the controllers rely only on the distributed "fact engine" for state, queried over RPC (currently AMQP). The NetworkController inserts most records into this datastore (allocating addresses, etc) - however, individual nodes update state e.g. when running instances crash.
While copies of this state exist in many places (expressed in IPTables rule chains, DHCP hosts files, etc), the controllers rely only on the distributed "fact engine" for state, queried over RPC (currently AMQP). The NetworkController inserts most records into this datastore (allocating addresses, etc) - however, individual nodes update state e.g. when running instances crash.
The Public Traffic Path
-----------------------
Public Traffic::
(PUBLIC INTERNET)
|
<NAT> <-- [RoutingNode]
<NAT> <-- [RoutingNode]
|
[AddressingNode] --> |
( VLAN )
( VLAN )
| <-- [BridgingNode]
|
<RUNNING INSTANCE>
<RUNNING INSTANCE>
The RoutingNode is currently implemented using IPTables rules, which implement both NATing of public IP addresses, and the appropriate firewall chains. We are also looking at using Netomata / Clusto to manage NATting within a switch or router, and/or to manage firewall rules within a hardware firewall appliance.
The RoutingNode is currently implemented using IPTables rules, which implement both NATing of public IP addresses, and the appropriate firewall chains. We are also looking at using Netomata / Clusto to manage NATting within a switch or router, and/or to manage firewall rules within a hardware firewall appliance.
Similarly, the AddressingNode currently manages running DNSMasq instances for DHCP services. However, we could run an internal DHCP server (using Scapy ala Clusto), or even switch to static addressing by inserting the private address into the disk image the same way we insert the SSH keys. (See compute for more details).
Similarly, the AddressingNode currently manages running DNSMasq instances for DHCP services. However, we could run an internal DHCP server (using Scapy ala Clusto), or even switch to static addressing by inserting the private address into the disk image the same way we insert the SSH keys. (See compute for more details).

25
doc/source/services.rst
View File

@@ -1,6 +1,6 @@
..
Copyright 2010 United States Government as represented by the
Administrator of the National Aeronautics and Space Administration.
Administrator of the National Aeronautics and Space Administration.
All Rights Reserved.
Licensed under the Apache License, Version 2.0 (the "License"); you may
@@ -15,17 +15,18 @@
License for the specific language governing permissions and limitations
under the License.
Services
========
.. _service_manager_driver:
Admin guide should go beyoned concepts & introduction by talking about how
each service interacts with each other, what requirements for deployment are,
monotoring, logging, etc
Services Managers and Drivers
=============================
Describe division of responsibilities for each component.
* nova-api
* nova-scheduler
* nova-compute
* nova-volume
* nova-network
* nova-instancemonitor
Service
-------
Manager
-------
Driver
------