57c4e9b6c6
The changes here are substantial and widespread, but in summary:
- We use cfg to parse the CLI and config files, rather than optparse
and PasteDeploy
- A schema is defined for all configuration options close to the code
which uses the option
- 2 ConfigOpts sub-classes are added to config.py basically just
defining how to find config files; this means we can now use e.g.
glance.conf for base config values which glance-api.conf can
override
- load_paste_app() is changed to load the paste app from the last
config file in the stack and pass the app the ConfigOpts instance
- The generic app and filter factories in wsgi.py are modified to
pass a ConfigOpts instance to the apps and filters
- A ConfigOpts subclass is added for the unit tests which writes out
config values to a temporary config file and uses cfg to parse that
I've tried to keep the switch as unobtrusive as possible leaving further
cleanups for later e.g.
- Moving PasteDeploy config out of the config files - I think it would
be good to aim for having users modify the PasteDeploy config files
only in fairly rare circumstances. To achieve this, we might define
a number of common pipelines in the PasteDeploy config and allow
the user to choose between those pipelines in the glance config.
- We should add help strings to all the opts, even just for the sake
of documenting them
- We should move a bunch of the options into groups - e.g. all the
rabbit options
- We no longer rely on config files for default values, so the default
config files could contain nothing but comments - i.e. explaining
each option and showing what the default for it is - making it
obvious where a user has explicitly set a value
There are a couple of behavioural changes which I don't think are
signifcant but are worth mentioning:
- We used to support passing a config file as a positional argument
but don't anymore; AFAICT, it was only used by glance-manage when
launching servers and I've changed that to pass --config-file
- log_opt_values() doesn't log unknown opts, so won't log any values
for opts which get registered at runtime later
Change-Id: Iafa998a2a8d860f1ad57e2cd2afee69686ed58ba
|
||
|---|---|---|
| bin | ||
| doc | ||
| etc | ||
| glance | ||
| tools | ||
| .bzrignore | ||
| .gitignore | ||
| .gitreview | ||
| .mailmap | ||
| Authors | ||
| MANIFEST.in | ||
| README | ||
| pylintrc | ||
| run_tests.py | ||
| run_tests.sh | ||
| setup.cfg | ||
| setup.py | ||
README
======
Glance
======
Glance is a project that defines services for discovering, registering,
retrieving and storing virtual machine images. The discovery and registration
responsibilities are handled by the `glance-registry` component while the
retrieval and storage responsiblities are handled by the `glance-api`
component.
Quick Start
-----------
If you'd like to run trunk, you can clone the git repo:
git clone git@github.com:openstack/glance.git
Install Glance by running::
python setup.py build
sudo python setup.py install
By default, `glance-registry` will use a SQLite database. If you'd like to use
MySQL, or make other adjustments, you can modify the glance.cnf file (see
documentation for more details).
Now that Glance is installed, you can start the service. The easiest way to
do that is by using the `glance-control` utility which runs both the
`glance-api` and `glance-registry` services::
glance-control all start
Once both services are running, you can now use the `glance` tool to
register new images in Glance.
glance add name="My Image" < /path/to/my/image
With an image registered, you can now configure your IAAS provider to use
Glance as its image service and begin spinning up instances from your
newly registered images.