Prevents the db from being created automatically when services run.
Adds nova-manage db sync and nova manage db version to bring the db up-to-date and to check the current version. Must be run with the same privileges as the services who will access the database (or you need to chmod the db afterwards if sqlite)
Outstanding issues:
- many style violations, especially in docstrings (leading spaces, extra newlines)
- no test coverage
- unusual defaults in the database columns (-1?)
- unusual naming "phy_resource"
The database changes in particular should preclude the original from being merged until they are correct, and for a patch of this scope some tests are really necessary for the new functionality.
The patch needs further review and should not be rushed in for bexar as it commits us to a variety of data model decisions that require more input.
Images may be streamed raw, or will be streamed into the right place to allow room for an MBR and partition table, if using non-raw images. PV vs HVM detection now occurs on the image, immediately after it has been streamed. External kernel / ramdisk are also supported in this mode.
Unit test changes include a partial Glance simulator, which is stubbed in place of glance.client.Client. This allows us to pass through the VM spawn path with either glance or objectstore backends enabled; the unit tests now cover both. A dependency upon glance has been added to pip-requires, in order to pull the Glance client code into the venv.
This includes minor fixes to nova.image.glance. This code is expected to be heavily reworked anyway with the image-service-use-glance-clients work.
1. nova.db.service.sqlalchemy.model.Serivce (adding a column to database)
2. nova.service ( nova-compute needes to insert information defined by 1 above)
So, db migration is necessary for existing user, but just adding columns.
This is accomplished by having the ImageService create a 'queued' image in Glance.
When the image is subsequently uploaded, the image will go from 'queued' -> 'saving' -> 'queued'.
Related Future Work:
The ImageService needs to be cleaned up so that there is a canonical set of attributes (id, status, etc), and a canonical set of values ('queued', 'saving', etc). Right now, EC2 is fairly coupled to LocalImageService and S3ImageService while OpenStackAPI is coupled to GlanceImageService; ideally, we should be able mix-and-match from any of these.
Example output from command-line tool:
(.nova-venv)termie@preciousroy:p/nova/easy_api % ./bin/stack
usage: stack [options] <controller> <method> [arg1=value arg2=value]
`stack help` should output the list of available controllers
`stack <controller>` should output the available methods for that controller
`stack help <controller>` should do the same
`stack help <controller> <method>` should output info for a method
./bin/stack:
-?,--[no]help: show this help
--[no]helpshort: show usage only for this module
--[no]helpxml: like --help, but generates XML output
--host: Direct API host
(default: '127.0.0.1')
--port: Direct API host
(default: '8001')
(an integer)
--project: Direct API project
(default: 'proj1')
--user: Direct API username
(default: 'user1')
Available controllers:
reflect Reflection methods to list available methods.
compute API for interacting with the compute manager.
(.nova-venv)termie@preciousroy:p/nova/easy_api % ./bin/stack help reflect
Available methods for reflect:
get_controllers List available controllers.
get_methods List available methods.
get_method_info Get detailed information about a method.
(.nova-venv)termie@preciousroy:p/nova/easy_api % ./bin/stack help reflect get_method_info
get_method_info(method):
Get detailed information about a method.
(.nova-venv)termie@preciousroy:p/nova/easy_api % ./bin/stack reflect get_method_info method=/reflect/get_method_info
{u'args': [[u'method']],
u'doc': u'Get detailed information about a method.',
u'name': u'get_method_info',
u'short_doc': u'Get detailed information about a method.'}
Vishvananda Ishaya