openstack/nova-specs
Code Issues Proposed changes

Fix a bunch of typos in approved liberty specs

Browse Source 
Change-Id: Ia83c7b3bb9bf5aecbe9d07382785c6e3e71c46b9
This commit is contained in:
Joe Gordon
2015-06-09 14:24:55 +03:00
parent e32744eeac
commit b4e9eb1a0b
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. each others work leading to a plethora of incomplete & inconsistent databases.
The libosinfo project started as an attempt to provide a common solution for The libosinfo project started as an attempt to provide a common solution for
virtualization applications to use when configuring virtual machines. It 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 including facts such as the supported device types, minimum resource level
requirements, installation media and more. Around this database is a C API for requirements, installation media and more. Around this database is a C API for
querying information, made accessible to non-C languages (including python) via 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 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 hardware settings for each operating system. This is the trap most previous
virtualization applications have fallen into. This has a significant burden 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 undesirable to attempt to try to reinvent the libosinfo wheel which is already
mostly round in shape. mostly round in shape.
@@ -289,7 +289,7 @@ Work Items
Dependencies 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 project/library. This will be accessed by the GObject introspection Python
bindings. On Fedora / RHEL systems this will entail installation of the bindings. On Fedora / RHEL systems this will entail installation of the
'libosinfo' packages and either the 'pyobject2' or 'python3-gobject' packages '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. The unit tests will of course cover the new code.
To test in Tempest would need a gate job which has the suitable packages 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 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 property and then verify that the guest virtual machine has received the
expected configuration changes. 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: 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 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. policy improvement and rest of those works will be continue in Liberty.
The detail is described at 'Work Items' section. 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 V2.1: api:[extension_alias]:[action]
For ec2: ec2_api:[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. 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. Micro-version, the version will be changed often.
* For volume related extensions, there isn't any thing can do, there already * 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. that of the lowest common denominator of databases supported by Nova.
This would also require changes to sqlalchemy-migrate to be able to 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 Another option would be remove the use of sqlalchemy-migrate for schema
changes altogether. The 'db sync' command to nova-manage would be 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 remove volumes already attached. This is essentially the purpose of
Nova's libvirt volume drivers. 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. 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 This spec lays out the removal of the duplicate code in Nova's