openstack/nova-specs
Code Issues Proposed changes

Merge "Fix a bunch of typos in approved liberty specs"

Browse Source
This commit is contained in:
Jenkins
2015-06-11 23:50:36 +00:00
committed by Gerrit Code Review
parent a52fe74e87 b4e9eb1a0b
commit d9ac404a65
4 changed files with 9 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
specs/liberty/approved/libvirt-hardware-policy-from-libosinfo.rst
View File

@@ -48,7 +48,7 @@ though, each project has tried to reinvent the wheel each time duplicating
each others work leading to a plethora of incomplete & inconsistent databases.
The libosinfo project started as an attempt to provide a common solution for
virtualization applications to use when configuring virtual machines. It
provides a user extendable database of information about operating systems,
provides a user extendible database of information about operating systems,
including facts such as the supported device types, minimum resource level
requirements, installation media and more. Around this database is a C API for
querying information, made accessible to non-C languages (including python) via
@@ -171,7 +171,7 @@ Alternatives
A 1st alternative would be for Nova to maintain its own database of preferred
hardware settings for each operating system. This is the trap most previous
virtualization applications have fallen into. This has a significant burden
because of the huge variety of operating systems in existance. It is
because of the huge variety of operating systems in existence. It is
undesirable to attempt to try to reinvent the libosinfo wheel which is already
mostly round in shape.
@@ -289,7 +289,7 @@ Work Items
Dependencies
============
The Nova libvirt driver will gain an optional dependancy on the libosinfo
The Nova libvirt driver will gain an optional dependency on the libosinfo
project/library. This will be accessed by the GObject introspection Python
bindings. On Fedora / RHEL systems this will entail installation of the
'libosinfo' packages and either the 'pyobject2' or 'python3-gobject' packages
@@ -308,7 +308,7 @@ Testing
The unit tests will of course cover the new code.
To test in Tempest would need a gate job which has the suitable packages
installed. This can be achieved by updating devstack to install the neccessary
installed. This can be achieved by updating devstack to install the necessary
bits. Some new tests would need to be created to set the new glance image
property and then verify that the guest virtual machine has received the
expected configuration changes.

6
specs/liberty/approved/nova-api-policy.rst
View File

@@ -12,7 +12,7 @@ https://blueprints.launchpad.net/nova/+spec/nova-api-policy-final-part
NOTE: This spec follow up the rest work of nova api policy blueprint:
https://blueprints.launchpad.net/nova/+spec/v3-api-policy , In the Kilo
The v2.1 policy improvement already finshed, but only finished part of db
The v2.1 policy improvement already finished, but only finished part of db
policy improvement and rest of those works will be continue in Liberty.
The detail is described at 'Work Items' section.
@@ -137,9 +137,9 @@ REST API layer is the place to enforce policy consistently.
For V2.1: api:[extension_alias]:[action]
For ec2: ec2_api:[action]
* We won't use 'compute' and 'compute_extension' to distingish the core and
* We won't use 'compute' and 'compute_extension' to distinguish the core and
extension API. Because the core API may be changed in the future.
* We also remove the API verison from the policy rule. Because after we have
* We also remove the API version from the policy rule. Because after we have
Micro-version, the version will be changed often.
* For volume related extensions, there isn't any thing can do, there already

2
specs/liberty/approved/online-schema-changes.rst
View File

@@ -159,7 +159,7 @@ This limits the schema changes that can be safely executed online to
that of the lowest common denominator of databases supported by Nova.
This would also require changes to sqlalchemy-migrate to be able to
manage seperate streams of migrations.
manage separate streams of migrations.
Another option would be remove the use of sqlalchemy-migrate for schema
changes altogether. The 'db sync' command to nova-manage would be

2
specs/liberty/approved/use-os-brick-library.rst
View File

@@ -28,7 +28,7 @@ initiator information, discover volumes being attached to a host and to
remove volumes already attached. This is essentially the purpose of
Nova's libvirt volume drivers.
Cinder has offically removed the embedded brick library and has switched
Cinder has officially removed the embedded brick library and has switched
to using the pypi os-brick library at the start of the Liberty release.
This spec lays out the removal of the duplicate code in Nova's