- Launchpad Entry: NovaSpec:related-images
- Created: RickHarris
- 1 Summary
- 2 Release Note
- 3 Rationale
- 4 User stories
- 5 Assumptions
- 6 Design
- 7 Implementation
- 8 Test/Demo Plan
- 9 Unresolved issues
- 10 BoF agenda and discussion
- 11 Attachments
Wthin Nova and Glance, there is currently no mechanism for relating instances and images. This means, as of right now, we cannot query for a list of images for a particular customer, and, when it comes time to write the backup scheduler, we have no way of querying for a list of images given a particular instance.
This proposal aims to add a new mechanism which will allow OpenStack deployments to relate images to instances without creating an unecessary coupling between Glance and Nova. Moreover, since not all OpenStack deployments will want to maintain this mapping of instances and images, this blueprint introduces this functionality as an option which can be configured in both Nova and Glance.
- Image-list now displays only images available to a given customer
- Snapshots are now related to the instance they were snapshotted from
- Alice creates a snapshot using the OpenStack API, when she retrieves a list of her available images, that image should be included while not including images from other customers.
- Backup Scheduler kicks off a nightly backup for Instance 123. The Backup Scheduler should be able to query for the backups associated with instance 123.
We would like to maintain a loose-coupling between Nova and Glance; Glance should, by default, not know anything about Nova; and, Nova, by default, should not know anything about Glance.
Many-to-Many Novas to Glances
Glance and Nova should possess a many-to-many-relationship between them; i.e. one Nova can talk to many Glance instances and one Glance instance can service many Nova instances. (Currently Nova supports only one Glance instance; this, however, is merely a convenience imposed to bootstrap Nova/Glance integration and not part of the core-architecture. As Nova and Glance mature, we expect to remove this restriction in Nova).
The central theme of this design is that instance-aware images are not required by all OpenStack installations and should therefore be treated as an optional feature.
To facilitate this we propose making a few small changes to Nova as well as some additions to Glance.
We're currently using a WSGI stack throughout Glance. We propose adding a WSGI middleware layer which adds instance-aware images (aka related-images) to the core glance-registry.
The InstanceAwareMiddleware layer will intercept the requests, parse out any instance related metadata, store that in a separate table (or even a separate system if need be), strip out the instance metadata, and then pass the request up to the core Glance registry component.
As mentioned in the assumptions section, a requirement is that Glance be able to support more than one Nova installation. Since instance_ids in Nova are simply sequential IDs and not globally unique, we will need to create a globally unique identifier for the Nova installation which we can store with the instance metadata. This (nova_installation_uuid, instance_id) tuple would be globally unique.
In order to pass this (nova-installation_uuid, instance_id) tuple to Glance without requiring all OpenStack deployments use this configuration, we propose a new optional ImageService that supplies this instance-metadata in the request. For sake of this document (we reserve the right to change the actual name during implementation), we can call it InstanceAwareGlanceImageService.
Implementation will require add the instance-aware WSGI middleware. This will be kept in an optional middlewares directory.
This WSGI middleware will make use of an instance-image mapping table. For the first cut, we propose that this table exists within the Glance database. However, since the architecture makes clear that this table is optional, in the future, we can move this table out to a separate system.
We will need to add a globally unique identifier for Nova installations. Since the related-image BP will be the only functionality will be the only feature that uses it, for now, the identifer can be optional. In time, however, we anticipate that this identifer will be necessary for other features, so we would recommend that all deployments generate one.
The Nova Identifier would simply be a UUID that is generated when Nova is first deployed. The identifier will be stored as a gflag.
To faciliate generating this UUID, we can add a helper to nova-manage which generates this UUID. For example
$ nova-manage generate-installation-uuid --nova-installation-uuid=ABCD-1234-ABCD-1234
Described in Implemenation.
The end-goal is support the concept of OpenStack API images being tied to instances. To test this we can:
1. Use unit-tests where we stubout an InstanceAwareGlanceImageService. We can then make the image listing calls to the OpenStack API within a customer context and should only see customer's image (plus public images).
2. We will also need functional tests to ensure that this process works end-to-end. Since an automated functional test framework isn't in place yet (it's being developed), we will need enact this testing manually.
This BP is highly-related to Auth since Image Listing requests occur within the context of a customer. Since Auth is, as of this moment, still a somewhat moving target, the interaction between the Auth system and the OpenStack API is a question-mark.
BoF agenda and discussion
How will Image listings interact with the OpenStack API auth mechanism.
How many potential OpenStack deployers will want Instance-Aware Images? (e.g. is Rackspace the only one? or will everybody want this?)