Difference between revisions of "AdministrativeVMs"

Latest revision as of 23:31, 17 February 2013

• Launchpad Entry: NovaSpec:administrative-vms
• Created: 04/17/2011
• Contributors:

Summary

Create a standard way of defining administrative vms / containers. These are vms that can plug into a project network (or management network) but are managed by the provider instead of the end user.

Release Note

The proposed blueprint will extend current external APIs by adding additional optional category parameter to instance-related APIs. Users should be able to continue using current version and will not notice any difference in behavior. This set of changes will also require database schema update and migration.

Rationale

Currently we have one type of administrative VM that is handled through custom code paths (pipelib.py) . VMs of this nature are very useful for providing various cloud services such as load balancing, queuing systems, databases, load balancers, network bridging components, etc. We need a consistent way to define these administrative vms, as well as apis for controlling them. This common definition should support both containers and traditional vms, perhaps even colocated on the same infrastructure.

Some types of administrative VMs might be managed by the provider, while others might be indirectly managed by the user through special interfaces/UI. One of examples of such instances is Virtual Storage Arrays/Controllers created by users, but users have no direct access to them (only to GUI, etc.)

User stories

• Allow creation of special instances/VMs inside of the project that are managed by cloud administrator or by the user indirectly
• Allow different types of Admin instances
  • Way to distinguish between regular compute and admin instances
  • Filter/block operations with admin instances
• Be able to specify requirements for Admin instances (like HW req)
  • Per type of instance
  • (future) Per instance
• (future) Be able to register special flavors for admin instances
• Run Admin instances on compatible nodes (e.g, where allowed or on nodes matching HW requirements)
• Admin VMs are created from special images
  • Way to distinguish between regular and admin images
  • Filter/block operations with registered admin images
• Allow assignment of volumes to Admin instances
  • Way to distinguish between regular volumes and volumes assigned to admin instances
  • Filter/block operations with admin volumes
  • (future) Allow assignment of admin volumes to multiple Admin instances

Assumptions

Design

Taking into account that admin VMs are compute instances with special parameters, it is proposed to extend current APIs and add a new instance category parameter that will distinguish between types of instances.

In general, handling of instance categories will be similar to instance_types / flavors.

Supported operations with instance categories:

• Create
• Update
• Destroy
• Purge
• Different get_by_*

Each category will have:

• Unique category name
• Description
• Default Image ID
• (future) Default instance_type / flavor
• Special HW requirements or other meta-data that will be used by scheduler (in form of key/value):
  • Availability of 10GbE NICs
  • NICs with SR-IOV
  • Local SSD storage
  • etc…

Regular EC2 APIs might be used for spawning/terminating/rebooting/describing some types of administrative instances, while other types might be controlled by calling compute_apis directly.

Default behavior of these APIs will not be changed if category was not specified:

• DescribeInstances API will report only non-admin instances for regular users or all instances for admin user calls
• RunInstances will assume Regular category by default
• Terminate/Reboot Instances performed for admin instances by regular user (non-admin) without specifying category name will be rejected

Having categories in a separate table will give us an opportunity in the future to establish relations between instance flavors and categories and register flavors for each category of instances. It will also allow us to store default values for different categories and simplify filtering of instances (check instance category id instead of parsing meta-data)

Filtering of images:

• Images registered for admin instances (in instance_categories table) will be filtered out during DescribeImages call if user is not admin

Filtering of volumes:

• Volumes assigned to admin instances will be filtered out during DescribeVolumes call if user is not admin

Implementation

UI Changes

Code Changes

Networking

TBD after multi-NIC

Authentication

TBD

Migration

• New instance_categories table is added with 1..N relations to instances by instance_cat_id
• New field instance_cat_id in instances table is added. By default filled with category id associated with regular instance types. If image_id for instance equals to FLAGS.vpn_image_id - category ID is set to FLAGS.instance_cat_vpn

Test/Demo Plan

This need not be added or completed until the specification is nearing beta.

Unresolved issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.