openstack/nova-specs
Code Issues Proposed changes

Mark specs implemented in kilo as implemented

Browse Source 
Just move implemented specs to the right place.

Change-Id: Ia09ed6aceb9e9874e07c740d2fe94ce1b88af9f7
This commit is contained in:
Michael Still
2015-03-23 11:27:10 +11:00
parent 5787b35423
commit 547a3fa4fa
24 changed files with 23 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

167
specs/kilo/implemented/add-all-in-list-operator-to-extra-spec-ops.rst Normal file
View File

@@ -0,0 +1,167 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
======================================
Add ALL-IN operator to extra spec ops
======================================
`https://blueprints.launchpad.net/nova/+spec/add-all-in-list-
operator-to-extra-spec-ops
<https://blueprints.launchpad.net/nova/+spec/add-all-in-list-
operator-to-extra-spec-ops>`_
Allow extra spec to match all values in a list by adding the ALL-IN operator.
Problem description
===================
This blueprint aims to allow querying if ALL of the given values are present
in a list.
Currently there's support for an IN operator that returns True if a given
element is present in a list. There is also an OR operator that
only works for single values.
Use Cases
---------
Suppose operator or user want a flavor that will place VMs on a host that has
the cpu flags 'aes' and 'vmx'. As it is today is not possible since the only
posibility is to use the <in> operator. But, as the extra specs is a dict, the
flavor extra-spec key would be the same:
capabilities:cpu_info:features : <in> aes
capabilities:cpu_info:features : <in> vmx
Just one of them will be saved.
Something like this is needed:
capabilities:cpu_info:features : <all-in> aes vmx
Project Priority
----------------
This blueprint doest't fit into scheduler priorities for Kilo. It was accepted
for Juno.
Proposed change
===============
We need to add the new <all-in> operator and its lambda function to
_op_methods dict in extra_specs_ops.py.
...
'<all-in>': lambda x, y: all(val in x for val in y),
...
Then add a call to this function with a list, instead of with a
string if there are more than one element in the query.
Alternatives
------------
Instead of add the '<all-in>' operator extend/overload the '<in>' operator to
work with a list.
capabilities:cpu_info:features : <in> aes vmx
Seems to be easy to understand but could generate confusion because <in>
operator as it is today, aims to be used to match a substring.
Another possibility is add both <any> and <all> operators. By doing this, we
are using <in> and <or> for single values and the new set of operators for
collections values. But something is missing with this approach,
<all> or <any> what? All elements in a list, all elements are True, or all
elements are equal to a given value.
Data model impact
-----------------
None
REST API impact
---------------
None
Security impact
---------------
None
Notifications impact
--------------------
None
Other end user impact
---------------------
None
Performance Impact
------------------
None
Other deployer impact
---------------------
None
Developer impact
----------------
None
Implementation
==============
Add a new lamda function to
nova/scheduler/filter/extra_specs_ops.py _ops_method dict:
'<all-in>': lambda x, y: all(val in x for val in y)
Assignee(s)
-----------
Primary assignee:
artur-malinowski
Other contributors:
pawel-koniszewski
facundo-n-maldonado
Work Items
----------
The change is simple and can be done in one Gerrit patch. Implementation is
acutally completed.
Dependencies
============
None
Testing
=======
Unit tests should be added for the new operator.
Documentation Impact
====================
Filter scheduler documentation should be updated with the new operator.
References
==========
* Approved spec for Juno: https://review.openstack.org/#/c/98179/
* Implementation: https://review.openstack.org/#/c/102631/

472
specs/kilo/implemented/api-microversions.rst Normal file
View File

@@ -0,0 +1,472 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
==========================================
REST API Microversion Support
==========================================
https://blueprints.launchpad.net/nova/+spec/api-microversions
We need a way to be able to introduce changes to the REST API to both
fix bugs and add new features. Some of these changes are backwards
incompatible and we currently have no way of doing this.
Problem description
===================
As a community we are really good at evolving interfaces and code over
time via incremental development. We've been less good at giant big
bang drops of code. The Nova API has become sufficiently large, and
constantly growing through new extensions, that it's not likely to be
able to ever do a new major version of the API because of the impact
on users and overhead for developers of supporting multiple
implementations.
At the same time the current situation where we allow innovation in
the API through adding extensions, has grown to the point where we now
have extensions to extensions, under the assumption that the extension
list is a poor man's versioning mechanism. This has led to large
amounts of technical debt. It prevents us from making certain changes,
like deprecating pieces of the API that are currently non sensible or
broken. Or fixing other areas where incremental development has led to
inconsistencies in the API which is confusing for new users.
We must come up with a better way that serves the following needs:
- Makes it possible to evolve the API in an incremental manner, which
is our strength as a community.
- Provides backwards compatibility for users of the REST API.
- Provides cleanliness in the code to make it less likely that we'll
do the wrong thing when extending or modifying the API.
A great interface is one that goes out of it's way to makes it hard to
use incorrectly. A good interface tries to be a great interface, but
bends to the realities of the moment.
Use Cases
----------
* Allows developers to modify the Nova API in backwards compatible
way and signal to users of the API dynamically that the change is
available without having to create a new API extension.
* Allows developers to modify the Nova API in a non backwards
compatible way whilst still supporting the old behaviour. Users of
the REST API are able to decide if they want the Nova API to behave
in the new or old manner on a per request basis. Deployers are able
to make new backwards incompatible features available without
removing support for prior behaviour as long as there is support
to do this by developers.
* Users of the REST API are able to, on a per request basis, decide
which version of the API they want to use (assuming the deployer
supports the version they want).
Project Priority
-----------------
The kilo priorities list is currently not defined. However under the
currently proposed list of priorities it would fall under "User
Experience" as it significantly increases the ability for us to
improve the Nova API.
Proposed change
===============
Design Priorities:
* How will the end users use this, and how to we make it hard to use
incorrectly
* How will the code be internally structured. How do we make it:
* Easy to see in the code that you are about to break API compatibility.
* Make it easy to make backwards compatible changes
* Make it possible to make backwards incompatible changes
* Minimise code duplication to minimise maintenance overhead
* How will we test this both for unittests and in integration. And
what limits does that impose.
Versioning
----------
For the purposes of this discussion, "the API" is all core and
optional extensions in the Nova tree.
Versioning of the API should be a single monotonic counter. It will be
of the form X.Y where it follows the following convention:
* X will only be changed if a significant backwards incompatible
API change is made which affects the API as whole. That is, something
that is only very very rarely incremented.
* Y when you make any change to the API. Note that this includes
semantic changes which may not affect the input or output formats or
even originate in the API code layer. We are not distinguishing
between backwards compatible and backwards incompatible changes in
the versioning system. It will however be made clear in the
documentation as to what is a backwards compatible change and what
is a backwards incompatible one.
Note that groups of similar changes across the API will not be made
under a single version bump. This will minimise the impact on users as
they can control changes that they want to be exposed to.
A backwards compatible change is defined as one which would be allowed
under the OpenStack API Change Guidelines
http://wiki.openstack.org/wiki/APIChangeGuidelines
A version response would look as follows
::
GET /
{
"versions": [
{
"id": "v2.1",
"links": [
{
"href": "http://localhost:8774/v2/",
"rel": "self"
}
],
"status": "CURRENT",
"version": "5.2"
"min_version": "2.1"
},
]
}
This specifies the min and max version that the server can
understand. min_version will start at 2.1 representing the v2.1 API
(which is equivalent to the V2.0 API except for XML support). It may
eventually be increased if there are support burdens we don't feel are
adequate to support.
Client Interaction
-----------------------
A client specifies the version of the API they want via the following
approach, a new header::
X-OpenStack-Nova-API-Version: 2.114
This conceptually acts like the accept header. This is a global API
version.
Semantically this means:
* If X-OpenStack-Nova-API-Version is not provided, act as if min_version was
sent.
* If X-OpenStack-Nova-API-Version is sent, respond with the API at that
version. If that's outside of the range of versions supported,
return 406 Not Acceptable.
* If X-OpenStack-Nova-API-Version: latest (special keyword) return
max_version of the API.
This means out of the box, with an old client, an OpenStack
installation will return vanilla OpenStack responses at v2. The user
or SDK will have to ask for something different in order to get new
features.
Two extra headers are always returned in the response:
X-OpenStack-Nova-API-Version: version_number, experimental
Vary: X-OpenStack-Nova-API-Version
The first header specifies the version number of the API which was
executed. Experimental is only returned if the operator has made a
modification to the API behaviour that is non standard. This is only
intended to be a transitional mechanism while some functionality used
by cloud operators is upstreamed and it will be removed within a small
number of releases..
The second header is used as a hint to caching proxies that the
response is also dependent on the X-Openstack-Compute-API-Version and
not just the body and query parameters. See RFC 2616 section 14.44 for
details.
Implementation design details
-----------------------------
On each request the X-OpenStack-Nova-API-Version header string will be
converted to an APIVersionRequest object in the wsgi code. Routing
will occur in the usual manner with the version object attached to the
request object (which all API methods expect). The API methods can
then use this to determine their behaviour to the incoming request.
Types of changes we will need to support::
* Status code changes (success and error codes)
* Allowable body parameters (affects input validation schemas too)
* Allowable url parameters
* General semantic changes
* Data returned in response
* Removal of resources in the API
* Removal of fields in a response object or changing the layout of the response
Note: This list is not meant to be an exhaustive list
Within a controller case, methods can be marked with a decorator
to indicate what API versions they implement. For example::
@api_version(min_version='2.1', max_version='2.9')
def show(self, req, id):
pass
@api_version(min_version='3.0')
def show(self, req, id):
pass
An incoming request for version 2.2 of the API would end up
executing the first method, whilst an incoming request for version
3.1 of the API would result in the second being executed.
For cases where the method implementations are very similar with just
minor differences a lot of duplicated code can be avoided by versioning
internal methods intead. For example::
@api_version(min_version='2.1')
def _version_specific_func(self, req, arg1):
pass
@api_version(min_version='2.5')
def _version_specific_func(self, req, arg1):
pass
def show(self, req, id):
.... common stuff ....
self._version_specific_func(req, "foo")
.... common stuff ....
Reducing the duplicated code to a minimum minimises maintenance
overhead. So the technique we use would depend on individual
circumstances of what code is common/different and where in the method
it is.
A version object is passed down to the method attached to the request
object so it is also possible to do very specific checks in a
method. For example::
def show(self, req, id):
.... stuff ....
if req.ver_obj.matches(start_version, end_version):
.... Do version specific stuff ....
.... stuff ....
Note that end_version is optional in which case it will match any
version greater than or equal to start_version.
Some prototype code which explains how this work is available here:
https://github.com/cyeoh/microversions_poc
The validation schema decorator would also need to be extended to support
versioning
@validation.schema(schema_definition, min_version, max_version)
Note that both min_version and max_version would be optional
parameters.
A method, extension, or a field in a request or response can be
removed from the API by specifying a max_version::
@api_version(min_version='2.1', max_version='2.9')
def show(self, req, id):
.... stuff ....
If a request for version 2.11 is made by a client, the client will
receive a 404 as if the method does not exist at all. If the minimum
version of the API as whole was brought up to 2.10 then the extension
itself could then be removed.
The minimum version of the API as a whole would only be increased by a
consensus decision between Nova developers who have the ovehead of
maintaining backwards compatibility and deployers and users who want
backwards compatibility forever.
Because we have a monotonically increasing version number across the
whole of the API rather than versioning individual plugins we will have
potential merge conflicts like we currenty have with DB migration
changesets. Sorry, I don't believe there is any way around this, but
welcome any suggestions!
Client Expectations
-------------------
As with system which supports version negotiation, a robust client
consuming this API will need to also support some range of versions
otherwise that client will not be able to be used in software that
talks to multiple clouds.
The concrete example is nodepool in OpenStack Infra. Assume there is a
world where it is regularly connecting to 4 public clouds. They are
at the following states::
- Cloud A:
- min_ver: 2.100
- max_ver: 2.300
- Cloud B:
- min_ver: 2.200
- max_ver: 2.450
- Cloud C:
- min_ver: 2.300
- max_ver: 2.600
- Cloud D:
- min_ver: 2.400
- max_ver: 2.800
No single version of the API is available in all those clouds based on
the ancientness of some of them. However within the client SDK certain
basic functions like boot will exist, though might get different
additional data based on version of the API. The client should smooth
over these differences when possible.
Realistically this is a problem that exists today, except there is no
infrastructure to support creating a solution to solve it.
Alternatives
------------
One alternative is to make all the backwards incompatible changes at
once and do a major API release. For example, change the url prefix to
/v3 instead of /v2. And then support both implementations for a long
period of time. This approach has been rejected in the past because of
concerns around maintance overhead.
Data model impact
-----------------
None
REST API impact
---------------
As described above there would be additional version information added
to the GET /. These should be backwards compatible changes and I
rather doubt anyone is actually using this information in practice
anyway.
Otherwise there are no changes unless a client header as described is
supplied as part of the request.
Security impact
---------------
None
Notifications impact
--------------------
None
Other end user impact
---------------------
SDK authors will need to start using the X-OpenStack-Nova-API-Version header
to get access to new features. The fact that new features will only be
added in new versions will encourage them to do so.
python-novaclient is in an identical situation and will need to be
updated to support the new header in order to support new API
features.
Performance Impact
------------------
None
Other deployer impact
---------------------
None
Developer impact
----------------
This will obviously affect how Nova developers modify
the REST API code and add new extensions.
FAQ
---
* Does adding a new plugin change the version number?
Yes.
* Do we bump a version number when error status codes change?
Yes, its is an API change.
Implementation
==============
Assignee(s)
-----------
Primary assignee:
cyeoh-0
Other contributors:
<launchpad-id or None>
Work Items
----------
* Implement APIVersions class
* Implement handling of X-OpenStack-Nova-API-Version header
* Implement routing of methods called based on version header.
* Find and implement first API change requiring a microversion bump.
Dependencies
============
* This is dependent on v2.1 v2-on-v3-api spec being completed.
* Any nova spec which wants to make backwards incompatible changes
to the API (such as the tasks api specification) is dependent on
on this change. As is any spec that wants to make any API change
to the v2.1 API without having to add a dummy extension.
* JSON-Home is related to this though they provide different
services. Microversions allows clients to control which version of
the API they are exposed to and JSON-Home describes that API
allowing for resource discovery.
Testing
=======
It is not feasible for tempest to test all possible combinations
of the API supported by microversions. We will have to pick specific
versions which are representative of what is implemented. The existing
Nova tempest tests will be used as the baseline for future API
version testing.
Documentation Impact
====================
The long term aim is to produce API documentation at least partially
automated using the current json schema support and future JSON-Home
support. This problem is fairly orthogonal to this specification
though.
References
==========
* https://etherpad.openstack.org/p/kilo-nova-microversions

177
specs/kilo/implemented/cells-instance-mapping.rst Normal file
View File

@@ -0,0 +1,177 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
==========================================
Cells instance mapping
==========================================
https://blueprints.launchpad.net/nova/+spec/cells-instance-mapping
In order for compute api nodes to communicate with the correct cell for an
instance there will need to be a mapping of instance to cell. A new table will
be created which can store this mapping.
Problem description
===================
When Nova is partitioned into cells, the compute api needs to know which cell
to communicate with for a particular instance. There is currently no mapping
of instance to cell in which it lives.
Use Cases
----------
* Operators want to partition their deployments into cells for scaling, failure
domain, and buildout reasons. When partitioned, we need a lookup table to
know which partition an instance is in.
Project Priority
-----------------
Cells v2 has been made a project priority for Kilo.
Proposed change
===============
The change being proposed is a new table in the 'nova_api' database for storing
a mapping of instance to cell. The database APIs and objects that interact
with this table will be updated to use it. Migration of data into this table
will be tackled in a separate spec.
The following diagram may help visualize it.::
api/cell boundary
nova show <uuid> |
| |
v |
nova-api+-------------------->cell-db
+ + |
| +----+ |
| | |
v v |
instance_mapping cell_mapping |
Alternatives
------------
We could continue to use the nova-cells model in place today.
Data model impact
-----------------
A new 'instance_mapping' table will be added to the 'nova_api' database.
The table will look like:::
CREATE TABLE `instance_mapping` (
`created_at` datetime DEFAULT NULL,
`updated_at` datetime DEFAULT NULL,
`id` int(11) NOT NULL AUTO_INCREMENT,
`instance_uuid` varchar(36) NOT NULL,
`cell_uuid` varchar(36) NOT NULL,
`project_id` varchar(255) NOT NULL)
And instance_uuid will be an indexed column. Other indexes are likely as well
and can be discussed in the code review.
It should be noted that there is no 'deleted' or 'deleted_at' column here.
This mapping is still valid even if the instance is deleted, so there is no
requirement to delete the mapping. A listing of deleted instances, for
example, will still need to know which cell those instances are in.
REST API impact
---------------
None
Security impact
---------------
None
Notifications impact
--------------------
None
Other end user impact
---------------------
None
Performance Impact
------------------
On its own this change does not introduce a performance impact. When it's used
by later specs it does introduce another database lookup for many actions
within Nova. For example a 'nova show <uuid>' will require Nova to look up the
database that an instance is in before it can query it for instance data. This
can be optimized later with a memcached cache of this mapping.
Other deployer impact
---------------------
This introduces a new table into the 'nova_api' database. And as described in
the "Data model impact" section above it should be considered when running any
cleanup on the instances table. If instances are removed from the instances
table they can be removed from the instance_mapping table as well.
Developer impact
----------------
Developers should be beginning to see that all instances in a deployment may
not be in the same database. But no development changes should necessary at
this point.
Implementation
==============
Assignee(s)
-----------
Primary assignee:
alaski
Other contributors:
None
Work Items
----------
* Add database migration for 'instance_mapping' table.
Dependencies
============
https://blueprints.launchpad.net/nova/+spec/cells-v2-mapping
Testing
=======
Since this is designed to be an internal re-architecting of Nova with no user
visible changes the current suite of Tempest or functional tests should
suffice. At some point we will want to look at how to test multiple cells or
potentially exposing the concept of a cell in the API and we will tackle
testing requirements then.
Documentation Impact
====================
Documentation should be added about the new table and what its usage will be.
References
==========
``https://etherpad.openstack.org/p/kilo-nova-cells``
``https://review.openstack.org/#/c/139191/``

217
specs/kilo/implemented/cells-v2-mapping.rst Normal file
View File

@@ -0,0 +1,217 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
==========================================
Cells v2 mapping
==========================================
https://blueprints.launchpad.net/nova/+spec/cells-v2-mapping
In order for compute api nodes to communicate with cells they will need to have
knowledge on how to connect to each cell. A new database and table will be
created which can store this information for use by the database and RPC layers
of Nova.
Problem description
===================
When Nova is partitioned into cells, the compute api needs to be able to
communicate with each one via a message bus and a database connection. There
is currently no mapping of a cell identifier to a message queue and database
connection. And there is no mechanism to dispatch RPC message or database
queries to different endpoints on a per call basis.
Use Cases
----------
* Developers who want to make database queries or send RPC messages to a
specific cell.
Project Priority
-----------------
Cells v2 has been made a project priority for Kilo.
Proposed change
===============
The change being proposed is a new database and table for storing a mapping of
cell to database and message queue. A new database is being proposed because
the new tables that will be added to it belong with the compute api layer of
Nova, as compared to some of the current tables which belong in a cells
database. The exact split of which information belongs where is an in-progress
effort.
The new database will require a separate line of migrations to be applied to
it. Since there have been discussions for a while now around potential
benefits of using alembic to handle db migrations this might be a good
opportunity to do so. I think it should be researched and used if there's
consensus that it would be beneficial and continue to use sqlaclhemy-migrate if
not.
Nova will need a connection string to connect to this new database and at the
same time continue to connect to the current 'nova' database until we can fully
migrate away from that. A new config option will be introduced to store the
connection info for the 'nova_api' database.
Additionally the database and rpc abstractions in Nova need to be capable of
communicating with an arbitrary endpoint for every call/query.
There is nothing in place to use this yet so the scope of work ends at just
having the capability to do it.
The following diagram may help visualize it. When a request comes in for an
instance in a cell nova-api will query the cell_mapping table to get the
necessary information for interacting with the cell database or message queue.
The instance to cell mapping is described in another spec.::
         api/cell boundary
|
|
+------------>cell-db
|      |
nova-api+--------->cell-mq
+       |
|       |
|       |
v       |
cell_mapping    |
Alternatives
------------
We could continue to use the nova-cells model in place today.
Data model impact
-----------------
A new 'cell_mapping' table will be added. And it will be added outside of the
current 'nova' database in a new 'nova_api' database. This new database will
have deployment ramifications as described below
The table will look like:::
CREATE TABLE `cell_mapping` (
`created_at` datetime DEFAULT NULL,
`updated_at` datetime DEFAULT NULL,
`deleted_at` datetime DEFAULT NULL,
`id` int(11) NOT NULL AUTO_INCREMENT,
`uuid` varchar(36) NOT NULL,
`name` varchar(255) DEFAULT NULL,
`deleted` int(11) DEFAULT NULL,
`transport_url` mediumtext NOT NULL,
`database_connection` mediumtext NOT NULL)
REST API impact
---------------
None
Security impact
---------------
The transport_url and database_connection fields in the database could contain
sensitive data.
Notifications impact
--------------------
None
Other end user impact
---------------------
None
Performance Impact
------------------
On its own this change does not introduce a performance impact. When it is
used by later specs it does introduce another database lookup for many actions
within Nova. For example a 'nova show <uuid>' will require Nova to look up the
database that an instance is in before it can query it for instance data. This
data will remain relatively stable and could be cached quite easily to help
offset any performance penalty.
Other deployer impact
---------------------
This blueprint introduces the concept of a database that is conceptually
distinct from the current nova database. Deployers will need to consider how
they want to manage a second database, whether it resides on the same host as
their current nova database or not. It will be used primarily by the nova-api
service so that should be considered when considering how to deploy it.
Developer impact
----------------
This change means that developers should understand that RPC messages or
database queries may hit one of many endpoints. At this point it should not
affect developers work within Nova. Developers adding future database
migrations will need to consider whether it goes at the API or cell level and
add it to the appropriate set of migrations.
Implementation
==============
Assignee(s)
-----------
Primary assignee:
alaski
Other contributors:
None
Work Items
----------
* Ensure Nova database API can communicate with an arbitrary database on each
call.
* Add config option for connecting to the new database.
* Research how to have a separate migration path within Nova for a new
database.
* Setup separate database migration path for migrations on a new database.
* Add database migration for 'cell_mapping' table.
Dependencies
============
None
Testing
=======
Since this is designed to be an internal re-architecting of Nova with no user
visible changes the current suite of Tempest or functional tests should
suffice. At some point we will want to look at how to test multiple cells or
potentially exposing the concept of a cell in the API and we will tackle
testing requirements then.
Documentation Impact
====================
The existence and management of a new database will need to be documented. It
is not required that the database be deployed at this time but deployers should
be prepped on how to start managing it.
References
==========
``https://etherpad.openstack.org/p/kilo-nova-cells``

183
specs/kilo/implemented/detach-service-from-computenode.rst Normal file
View File

@@ -0,0 +1,183 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
================================
Detach Service from Compute_Node
================================
https://blueprints.launchpad.net/nova/+spec/detach-service-from-computenode
Remove the nested dependency in between Service and ComputeNode
Problem description
===================
There is no good reason to keep a dependency in between a service, which is the
representation of the message bus and a compute_node, which is a collection of
resources for the solely use of the scheduler. The fact that they are related
to each other means that the resource tracker ends up needing to "find" its
compute node record by first looking up the service record for the 'compute'
topic and the host for the resource tracker, and then grabs the first
compute_node record that is related to the service record that matches that
query. There is no reason to do this in the resource tracker other than the
fact that right now the compute_nodes table has a service_id field and a
relation to the services table.
It also carries a dependency on the compute_nodes table as there is a foreign
key on a separate table for something totally unrelated to the Scheduler, which
prevents the Scheduler to be split unless we continue to carry that
relationship.
Use Cases
---------
This is a refactoring effort helping out to split the scheduler by reducing the
dependencies it has to manage.
Project Priority
----------------
This blueprint is part of the 'scheduler' refactoring effort, defined as a 3rd
priority for the Kilo release.
Proposed change
===============
Instead of having a relationship using a foreign key, the proposal will consist
of adding a new field called 'host' for compute_nodes and a unique constraint
on (host, hypervisor_hostname). Also, service_id field will be marked as
deprecated and not updated in the compute_nodes table and ComputeNode object
field service_id will be left unset. SQLA relationship on service will be
deleted and Service object will keep a compute_node field but will actually not
use this relationship.
Implementation proposal can be found in the patch series [1].
Alternatives
------------
Only change DB API to remove the relationship without changing callers but
it would create some confusion and obfuscate the need of modifying accessors.
Data model impact
-----------------
Most of the change is about changing the model, but let's rephrase it.
compute_nodes.service relationship will be deleted, compute_nodes.service_id
will be marked as deprecated and not updated by Kilo compute nodes and
compute_nodes.host will be added as a String (identical to Service.host field).
As it was agreed during Summit, no data migrations will happen for updating
either when creating the host column (for populating its values) or when
downgrading by repopulating service_id.
Instead, data migration (here service_id to host) will be managed at the Object
level (here ComputeNode) each time a save operation will happen by querying
Service object to get the host value and set service_id to NULL.
There is no sense to keep a specific ID while the tuple (host, node) is
identified as the source of truth for idenfifying compute nodes.
ComputeNode object will still continue to have a service field but it will
no longer use the relationship to get that info. In parallel, Service object
will continue to have a nested ComputeNode object for backwards compatibility
but won't also use the relationship to get that object.
REST API impact
---------------
In order to preserve API stability, we will still provide service information
when querying compute nodes but this extra information will be on a
case-by-case basis thanks to an extra flag passed to the DB API asking to join
service and compute_nodes tables on service.host == compute_nodes.host.
We expect no performance penalty as it is already done this way in
db.compute_node_get_all() with an INTEGER matching instead of a VARCHAR(255).
No changes in the API model.
Security impact
---------------
None
Notifications impact
--------------------
None
Other end user impact
---------------------
None
Performance Impact
------------------
None
Other deployer impact
---------------------
An external tool could be provided for migrating offline existing compute nodes
which don't yet have the host field set.
Developer impact
----------------
None
Implementation
==============
Assignee(s)
-----------
Primary assignee:
sbauza
Other contributors:
None
Work Items
----------
Code was already posted as a patch series [1] :
* Add host field to compute_nodes table
* Add extra methods for querying this new field
* Use these extra methods instead of querying Service for getting the node(s)
* Make service info optional when querying compute nodes
* Remove query by service_id on compute_nodes
* Do not provide by default service info when querying compute nodes
* Deprecate service_id field from compute_nodes and delete service relationship
Dependencies
============
None
Testing
=======
Current Tempest and unittests already cover this.
Documentation Impact
====================
None
References
==========
Formerly it was a bug:
https://bugs.launchpad.net/nova/+bug/1357491
[1]: https://review.openstack.org/#q,topic:bp/detach-service-from-computenode,n,z

352
specs/kilo/implemented/ec2-api-required-additions.rst Normal file
View File

@@ -0,0 +1,352 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
===========================================================
Nova changes required for standalone EC2 API implementation
===========================================================
https://blueprints.launchpad.net/Nova/+spec/ec2-api
Some of the information required for EC2 API, currently supported by
existing nova's EC2 API implementation is not exposed by public
nova APIs. This spec lists these omissions and provides suggestions
about how to expose them.
Problem description
===================
Existing EC2 API implementation in nova came to a state where it's deprecation
is discussed. A standalone EC2 API project was created as a replacement
(now it resides in stackforge - links at the bottom in References).
It needs to be able to cover the same feature-set as existing solution, for
which it needs to retrieve all of the necessary information through
public APIs of OpenStack services in order to satisfy EC2 API protocol.
Some of the required information is currently not exposed in public APIs.
Existing nova's EC2 API implementation gets it from internal nova interfaces or
directly from the nova DB.
As a result of this the standalone EC2 API service uses direct access to nova
DB as a temporary workaround to fill the gaps.
IMPORTANT: this spec discusses only the properties which are reported by
existing nova's EC2 API and which are lost for external EC2 API
implementation. There is in fact more information which will be eventually
required to be exposed in public APIs for maximum compatibility with AWS EC2,
but this will be a subject for different specs.
Use Cases
----------
1. End User uses fully functional EC2 API protocol to access OpenStack cloud as
the user used to working with AWS.
2. End User needs to access instance metadata service and fetch information
in EC2 metadata compatible format.
Project Priority
-----------------
API v2.1 is a project priority and this is an important microversion to have
in place before the release.
Proposed change
===============
Absent information is of different importance and consists of the following
(novaDB instances table):
1. Reservation-related information:
- reservation_id
- launch_index
2. Network-related information
- hostname
3. Image-related information
- kernel_id
- ramdisk_id
4. Metadata-related information
- user_data
5. Device-related information
- root_device_name
- delete_on_termination (block_device_mapping table)
6. Ephemeral-device-related information (metadata service only)
- List of ephemeral devices (block_device_mapping_table)
All of this information is available in NovaDB at the moment. But not all of
this information probably should reside there.
Almost all of this information can be stored in our external DB and be fully
supported for instances run and handled via EC2 API. So in fact the problem
exists almost only for instances run via nova.
The following is a more detailed description given to the best of our
current knowledge. Also our subjective priorities for exposure of this
information from nova API are given with reasoning (some of those we can
provide without affecting nova):
1. Reservation-related information (reservation_id, launch_index).
Importance: Low.
EC2: Reservation/reservationId
http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_Reservation.html
EC2: Instance/amiLaunchIndex
http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_Instance.html
Description:
The reservation ID and launch index are correctly stored and handled by
our external code for instances run via EC2 API. Problem concerns only
instances run directly from nova and in fact only the ones run using
os-multiple-creation API extension. Only then reservation and launch
index start making sense.
Nova itself does not report reservation ID except for creation operation
run with return_reservation_id flag set to True and os-multiple-creation
API extension present.
And launch index is in fact only a number in sequence of started instances
during group start for particular reservation (it's informational only and
it seems won't be missed much).
Solution:
- support it in nova and start reporting this reservation ID and
optionally Launch index as part of extended info.
"os-extended-server-attributes:reservation_id"
"os-extended-server-attributes:launch_index"
2. Network-related information (hostname)
Importance: Low
EC2: Instance/privateDnsName
http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_Instance.html
Description:
Currently correct hostname is returned by nova for usage with nova-network
only. It doesn't quite work correctly in nova at the moment. Also even for
nova-network based solution there is an option to report IP here instead of
hostname (ec2_private_dns_show_ip option).
Amazon generates this hostname from IP and zone:
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-hostname.html
Solution:
- support it in nova and start reporting this reservation ID and
optionally Launch index as part of extended info.
"os-extended-server-attributes:hostname"
3. Image-related information (kernel_id, ramdisk_id)
Importance: Low
EC2: Instance/kernelId
http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_Instance.html
EC2: Instance/ramdiskId
http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_Instance.html
Description:
Kernel and Ramdisk seemingly are not much used for instances run by nova
and are not very critical to report.
Solutions:
- support it in nova and start reporting this reservation ID and
optionally Launch index as part of extended info.
"os-extended-server-attributes:kernel_id"
"os-extended-server-attributes:ramdisk_id"
4. Metadata-related information (user_data)
Importance: Low
EC2: InstanceAttribute/userData
http://docs.aws.amazon.com/AWSEC2/latest/
APIReference/API_InstanceAttribute.html
Description:
This is user-specific info which is provided during instance creation and this
functionality works. Current nova's EC2 doesn't allow modification of userdata
so the biggest problem now is that we can't provide read-only access to it
from EC2 APIs without exposure in nova public interfaces. The problem stands
for both main EC2 API service and for EC2 metadata service.
Still user can access from by the nova metadata service url from inside the
instance:
http://169.254.169.254/openstack/userdata
Solutions:
- support it in nova and start reporting this reservation ID and
optionally Launch index as part of extended info.
"os-extended-server-attributes:userdata"
5. Device-related information (root_device_name, delete_on_termination)
Importance: Medium
EC2: Instance/rootDeviceName and rootDeviceType
http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_Instance.html
EC2: EbsInstanceBlockDevice/deleteOnTermination
http://docs.aws.amazon.com/AWSEC2/latest/
APIReference/API_EbsInstanceBlockDevice.html
Description:
Root device name is an informational property but it's the only means at the
moment to determine type of the rootDeviceType. rootDeviceType is EBS if
rootDeviceName can be found in a list of block devices (returned in BDM or
in list taken from cinder). The condition is a bit more complicated but in a
nutshell it's so.
deleteOnTermination is only stored in nova DB in block_device_mapping table
for each block device. And it's the only place to get it from. However,
it can be set even now so the only problem is that we do not report it
properly if we don't use novaDB directly.
Solutions:
- support it in nova and start reporting root_device-name and
delete_on_termination of extended info.
"os-extended-server-attributes:root_device_name".
"os-extended-volumes:volumes_attached" as a second key in the dictionary for
the attached volumes.
6. Ephemeral-device-related information (block_device_mapping_table)
Importance: Low
EC2: block-device-mapping/ephemeralN
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html
Description:
- We can report block devices taken from cinder in metadata, so only the
ephemeral devices list is absent at the moment. However, inside the instance
user can get information about devices from the system.
Solution:
- we suggest to not expose it at the moment
For Kilo all of these extensions are proposed to be added as a microversion to
the v2.1 API. Currently it looks like v2.4 microversion.
The whole list of introduced extensions would look like:
"OS-EXT-SRV-ATTR:reservation_id": "r-00000001"
"OS-EXT-SRV-ATTR:launch_index": 0
"OS-EXT-SRV-ATTR:kernel_id": "a5f474bf81474f9dbbc404d5b2e4e9b3"
"OS-EXT-SRV-ATTR:ramdisk_id": "b5f474bf81474f9dbbc404d5b2e4e9b3"
"OS-EXT-SRV-ATTR:hostname": "fake-hostname"
"OS-EXT-SRV-ATTR:root_device_name": "/dev/vda"
"OS-EXT-SRV-ATTR:userdata": "fake"
"os-extended-volumes:volumes_attached": "{"delete_on_termination": True, ...}"
Alternatives
------------
Some of the alternatives were explained above, however there are 3 general
paths in the short term (Kilo and first version of production standalone
EC2 API afterwards) we can take:
1. Not return any information in question.
2. Store everything in standalone EC2 API DB and provide all the information
for EC2 API run instances and some dummy values for nova-run instances.
All of the alternatives presume cutting direct novaDB access.
Data model impact
-----------------
stackforge/ec2-api brings it's own database.
Changes for novaDB are only the cutting of EC2-specific information not
exposed anymore by nova.
No changes required to expose necessary information in public APIs.
REST API impact
---------------
Depends on taken decisions.
New information exposed by public APIs can be put in some extended attributes
for instance listing like:
"os-extended-server-attributes:reservation_id"
"os-extended-server-attributes:launch_index"
"os-extended-server-attributes:kernel_id"
"os-extended-server-attributes:ramdisk_id"
"os-extended-server-attributes:userdata"
"os-extended-server-attributes:deleteOnTerminationDevices": "volume_id_1,
volume_id_2, ...."
Security impact
---------------
None
Notifications impact
--------------------
None
Other end user impact
---------------------
None
Performance Impact
------------------
None
Other deployer impact
---------------------
None
Developer impact
----------------
None
Implementation
==============
Assignee(s)
-----------
To expose decided public APIs
it's either stackforge/ec2-api team:
Primary assignee:
Alexandre Levine (alexandrelevine)
Other contributors:
Feodor Tersin (ftersin),
Andrey Pavlov (apavlov-e)
or nova team.
Work Items
----------
Expose decided public APIs
Dependencies
============
None
Testing
=======
Usual Unit and Tempest tests for nova APIs along with new stackfore/ec2-api
tests to check that it helped the initial problem.
Documentation Impact
====================
New APIs documentation
References
==========
The existing stackforge project:
https://github.com/stackforge/ec2-api
EC2 API Standalone service spec and blueprint:
https://blueprints.launchpad.net/nova/+spec/ec2-api
Gerrit topic: https://review.openstack.org/#q,topic:bp/ec2-api,n,z
Related mailing list threads:
http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg44704.html
https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg44548.html
Kilo Design Summit notes:
https://etherpad.openstack.org/p/kilo-nova-summit-unconference

176
specs/kilo/implemented/encryption-with-barbican.rst Executable file
View File

@@ -0,0 +1,176 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
======================================================
Make key manager interface interoperable with Barbican
======================================================
URL to Launchpad blueprint:
https://blueprints.launchpad.net/nova/+spec/encryption-with-barbican
The volume encryption feature added in the Havana release currently can only
operate with a single key that is hardcoded in. A much more flexible and
secure solution would be to generate and store keys in Barbican, a cohesive and
secure Linux-based key management system
https://github.com/cloudkeep/barbican/wiki, which is now in the OpenStack
incubation process.
Problem description
===================
Problem 1: The OpenStack Volume Encryption feature currently cannot provide its
designed level of security due to the absence of a key management service.
Only a placeholder is available now, which isn't sufficient for the volume
encryption feature to be used in an enterprise environment. Keys cannot be
stored, and only one hard-coded key is presented for all volumes. The proposed
outcome would provide the ability to create and safely store dedicated keys for
individual users or tenants.
Problem 2: An ephemeral disk encryption feature supporting LVM was not accepted
into the Icehouse release due to the lack of a key manager. For security
reasons, since the disk is in close proximity to the virtual host, ephemeral
disk encryption must use a key that's safely stored outside of the virtual host
environment.
An enterprise-grade key manager is needed for both cases, and Barbican
(approved for incubation on 3/10/14) is becoming the default key manager that
is slated to support OpenStack volume encryption, ephemeral disk storage
encryption, and other potential security features.
https://wiki.openstack.org/wiki/Barbican/Incubation. In order for Barbican to
support these two storage encryption features, an interface between the
existing key manager interface (nova/keymgr/key_mgr.py) used for volume
encryption and the Barbican key manager needs to be developed.
Use Cases
---------
Users who wish to use the OpenStack Volume Encryption feature currently don't
have the ability to have encryption on a per-tenant basis. It currently has
a single unchangable key. By adding the option of using the Barbican Key
Manager, a separate key can be created and stored for each tenant. This makes
the feature much more secure.
Project Priority
----------------
N/A
Proposed change
===============
Create an interface that will call python-barbicanclient, allowing Barbican to
securely generate, store, and present encryption keys to Nova in support of the
volume encryption feature. The adapter will be a modification of the present
key management abstraction layer in the volume encryption feature supporting
block storage encryption on Cinder and ephemeral disk encryption.
Alternatives
------------
Instead of implementing the existing key manager interface,
python-barbicanclient could be invoked directly, but the additional indirection
allows more extensibility if a different key manager needs to be integrated
later.
Data model impact
-----------------
None
REST API impact
---------------
None
Security impact
---------------
Use of a bonafide key manager greatly improves the security posture of the
volume encryption and upcoming ephemeral disk encryption features. When each
user or tenant use a unique key instead of a common key, and when it is stored
in a separate server, it will be much more difficult for an attacker to access
stored encrypted data owned by a user or group of collective users within a
tenant.
Though the wrapper will be handling encryption keys, the security risk is
considered minimal since the host must be trusted, and the wrapper is only
holding the key temporarily.
Notifications impact
--------------------
None
Other end user impact
---------------------
None
Performance Impact
------------------
The additional storage write and read time to initially query Barbican for the
encryption key should be negligible.
Other deployer impact
---------------------
Assuming that Barbican is the default key manager, then no impact. If it's not
the default, then a configuration flag in Nova will need to be added.
Developer impact
----------------
None
Implementation
==============
Assignee(s)
-----------
Primary assignee:
hadi-esiely-barrera
Other contributors:
brianna-poulos
bruce-benjamin
Work Items
----------
Develop simple translation of existing key manager interface methods (e.g.,
get_key) into the corresponding python-barbicanclient calls.
Dependencies
============
None
Testing
=======
Tempest testing should be performed to ensure that the wrapper works correctly.
Documentation Impact
====================
The use of Barbican as the default key manager for the storage encryption will
need to be documented.
References
==========
None

184
specs/kilo/implemented/input-output-based-numa-scheduling.rst Normal file
View File

@@ -0,0 +1,184 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
================================
I/O (PCIe) based NUMA scheduling
================================
https://blueprints.launchpad.net/nova/+spec/input-output-based-numa-scheduling
I/O based NUMA scheduling will add support for intelligent NUMA node placement
for guests that have been assigned a host PCI device.
Problem description
===================
Modern servers with two or more processors have a Non Uniform Memory
Architecture (NUMA). This means that there are different memory performance
and latency characteristics when accessing memory directly attached to one
processor than when accessing memory directly attached to another processor in
the same server. Similarly, PCIe I/O devices such as Network Interface Cards
(NICs), can be more closely associated with one processor than another.
The optimal configuration with multi NUMA node platforms is where all host
resources that the guest requires are associated with the same host NUMA node,
this will reduce or remove cross NUMA node memory traffic.
To reach a remote NUMA node the memory request must traverse the inter CPU
link and use the remote NUMA nodes associated memory controller to access the
remote node. This incurs a latency penalty on remote NUMA node memory access.
The default guest placement policy is to use any available physical CPU (pCPU)
from any NUMA node. This blueprint optimises Openstack guest placement by
ensuring that a guest bound to a PCI device is scheduled to run on a NUMA node
that is associated with the guests pCPU and memory allocation.
Use Cases
----------
A guest running workloads requires the use of networking and memory resources
from the host. For the use case where the guests resource requirements fit in
a single NUMA node, an optimally configured system all guest resources should
be associated with the same NUMA node. NFV represents an obvious use case for
when this is particularly important, but there are significant benefits for
other more "traditional" cloud and enterprise workloads.
Project Priority
-----------------
The kilo priorities list is currently not defined. However under the currently
proposed list of priorities it would fall under "Performance".
Proposed change
===============
Extend the PCI device model with a NUMA node field.
Libvirt versions > 1.2.6 will provide the NUMA node of a host PCI device we
will store this information in the nova DB for use during the guest placement
phase.
Extend the PCI device capabilities for libvirt config.
Extend the libvirt driver to capture the PCI devices numa node.
Extend PCI device tracker to track the PCI device NUMA node usage.
Nova scheduling will be enhanced to take consideration of a guests PCI device
requirements and the nodes available for placement.
The NUMA topology filter will be modified to ensure the guest is scheduled on
the requested host NUMA node.
Alternatives
------------
Libvirt supports integration with a NUMA daemon (numad) that monitors NUMA
topology and usage. It attempts to locate guests for optimum NUMA locality,
dynamically adjusting to changing system conditions. This is insufficient
because we need this intelligence in nova for host selection and node
deployment.
Data model impact
-----------------
The PciDevice model will be extended to add a field identifying the NUMA node
that PCI device is associated with.
numa_node = Column(Integer, nullable=True)
A DB migration script will use ALTER_TABLE to add a new column to the
pci_devices table in nova DB.
REST API impact
---------------
There will be no change to the REST API.
Security impact
---------------
This blueprint does not introduce any new security issues.
Notifications impact
--------------------
This blueprint does not introduce new notifications.
Other end user impact
---------------------
This blueprint adds no other end user impact.
Performance Impact
------------------
Associating a guests PCI device and RAM allocation with the same NUMA node
provides an optimal configuration that will give improved I/O throughput and
reduced memory latencies, compared with the default libvirt guest placement
policy.
This feature will add some scheduling overhead, but this overhead will deliver
improved performance on the host.
Other deployer impact
---------------------
To use this feature the deployer must use HW that is capable of reporting
NUMA related info to the OS.
Developer impact
----------------
This blueprint will have no developer impact.
Implementation
==============
Assignee(s)
-----------
Primary assignee:
James Chapman
Other contributors:
Przemyslaw Czesnowicz
Sean Mooney
Adrian Hoban
Work Items
----------
* Add a NUMA node attribute to the pci_device object
* Use libvirt to discover hosts PCI device NUMA node association
* Enable nova compute synchronise PCI device NUMA node associations with nova
DB
* Enable libvirt driver configure guests with requested PCI device NUMA node
associations
* Enable the nova scheduler decide on which host is best able to support
a guest
* Enable libvirt driver decide on which NUMA node to place a guest
Dependencies
============
The dependencies for this feature have been included in the Juno release.
Testing
=======
Unit tests will be added to validate these modifications.
Documentation Impact
====================
This feature will not add a new scheduling filter, but rather extend the
existing NUMNA topology filter. We will add documentation as required.
References
==========
None

253
specs/kilo/implemented/iscsi-live-migration-different-target.rst Normal file
View File

@@ -0,0 +1,253 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
=======================================================
Support iSCSI live migration for different iSCSI target
=======================================================
Include the URL of your launchpad blueprint:
https://blueprints.launchpad.net/nova/+spec/iscsi-live-migration-different-target
Currently, Nova premises a situation which iSCSI target is not changed
before and after live migration. Therefore, if destination node has
different iSCSI target, the live migration fails in current Nova's
specification. However, if each compute node uses same iSCSI target,
each compute node recognizes all volumes in the iSCSI target and this
is undesirable situation from the view point of security.
Therefore, this spec proposes to support live migration of instances with
Cinder volumes among compute nodes that need to log into different
iSCSI targets to access the volumes.
For your reference, if iSCSI storages have features to manage visibility
of LUNs for each initiator within one iSCSI target, using same iSCSI
target for each compute node is not a problem. But general iSCSI storages
don't have such kind features, therefore they need this feature to
support live migration.
Problem description
===================
In general, if multiple compute nodes use a same iSCSI target to export
volumes, each compute node recognizes all volumes in the target even if
some volumes are not attached to instances of a compute node.
This may cause slowdown of SCSI device scan if thousands of SCSI devices
are recognized on a compute node and also this is undesirable situation
from the view point of security.
On the other hand,
* Cinder LVM driver avoids this problem by creating unique iSCSI target
for each volume.
* Some enterprise iSCSI storages has features to manage visibility of
LUNs for each initiator within one iSCSI target.
But, generally storages have a limitation of a number of iSCSI target,
which is often less than maximum number of LUs.
In addition, there is a case that a storage does not have a feature
of visibility management of iSCSI target for multiple initiators.
In this case, by creating individual iSCSI target for each compute node and
managing visibility by connecting LUs to a corresponding iSCSI target
when the volumes is attached to instances on the node, we can avoid this
problem and utilize the storage capacity.
However, Nova currently premises a situation which iSCSI target is not
changed before and after live migration. Therefore, during live migration,
a source node pass a host device path which is created from the address of
iSCSI target portal, IQN, etc to destination node. This causes failure of
live migration if destination node has different iSCSI target.
In order to solve current problem, this spec proposes to support
of live migration for different iSCSI targets.
Use Cases
----------
Using this proposal, each compute node can utilize individual iSCSI target.
As a result, each compute node only recognizes volumes which are related to
a compute node. This can be reduce load of unnecessarily SCSI device scan,
udev high work load and decrease security risk.
Project Priority
-----------------
None.
Proposed change
===============
Following changes premise a result which each initiator returns
different iSCSI target IQN at initialize_connection() of Cinder
during live migration.
In libvirt driver,
(1) Store device path of block devices on destination host into
pre_live_migration_data during pre_live_migration() .....[EX1]
(2) Check "serial" field of each disk in domain definition XML.
Then, if the original "serial" and destination "serial" are same
value, replace "source dev" in the XML using device paths from
destination host .....[EX2]
QEMU built-in iSCSI initiator(libiscsi) will be supported during
Kilo phase. This proposal need to take account of both
iscsi-initiator case and libiscsi case.
* https://review.openstack.org/#/c/133048/
If the initiator is libiscsi, replace "name", "host name" and "port"
fields in the XML using res_data from destination host .....[EX3]
(3) Pass the new XML data to libvirt migrateToURI2 API.
[EX1]::
res_data
{'device_path': {u'58a84f6d-3f0c-4e19-a0af-eb657b790657':
u'/dev/disk/by-path/ip-192.168.0.10:3260-iscsi-iqn.abc.org.67890.
opst-lun-Z'},
'graphics_listen_addrs': {'vnc': '127.0.0.1', 'spice': '127.0.0.1'}}
[EX2]
For iscsi-initiator::
[Before]
<disk type='block' device='disk'>
<driver name='qemu' type='raw' cache='none'/>
<source dev='/dev/disk/by-path/
ip-192.168.0.10:3260-iscsi-iqn.abc.org.12345.opst-lun-X'/>
<target dev='vdb' bus='virtio'/>
<serial>58a84f6d-3f0c-4e19-a0af-eb657b790657</serial>
<address type='pci' domain='0x0' bus='0x0' slot='0x04' function='0x0'/>
</disk>
[After]
<disk type='block' device='disk'>
<driver name='qemu' type='raw' cache='none'/>
<source dev='/dev/disk/by-path/
ip-192.168.0.10:3260-iscsi-iqn.abc.org.67890.opst-lun-Z'/>
<target dev='vdb' bus='virtio'/>
<serial>58a84f6d-3f0c-4e19-a0af-eb657b790657</serial>
<address type='pci' domain='0x0' bus='0x0' slot='0x04' function='0x0'/>
</disk>
[EX3]
For libiscsi::
[Before]
<disk type='network' device='disk'>
<driver name='qemu' type='raw'/>
<source protocol='iscsi' name='iqn.abc.org.12345.opst/X'>
<host name='192.168.0.10' port='3260'/>
</source>
<serial>58a84f6d-3f0c-4e19-a0af-eb657b790657</serial>
<target dev='vdb' bus='virtio'/>
</disk>
[After]
<disk type='network' device='disk'>
<driver name='qemu' type='raw'/>
<source protocol='iscsi' name='iqn.abc.org.67890.opst/Z'>
<host name='192.168.0.10' port='3260'/>
</source>
<serial>58a84f6d-3f0c-4e19-a0af-eb657b790657</serial>
<target dev='vdb' bus='virtio'/>
</disk>
Alternatives
------------
None.
Data model impact
-----------------
None.
REST API impact
---------------
None.
Security impact
---------------
None.
Notifications impact
--------------------
None.
Other end user impact
---------------------
None.
Performance Impact
------------------
None.
Other deployer impact
---------------------
None.
Developer impact
----------------
None.
Implementation
==============
Assignee(s)
-----------
Primary assignee:
mtanino
Work Items
----------
These two patches will be posted.
1. Support iscsi-initiator
2. Support QEMU built-in iSCSI initiator(libiscsi)
Dependencies
============
None.
Testing
=======
- Unit tests should be added.
Documentation Impact
====================
None.
References
==========
None.

249
specs/kilo/implemented/isolate-scheduler-db-aggregates.rst Normal file
View File

@@ -0,0 +1,249 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
=========================================
Isolate Scheduler Database for Aggregates
=========================================
https://blueprints.launchpad.net/nova/+spec/isolate-scheduler-db
We want to split out nova-scheduler into gantt. To do this, this blueprint is
the second stage after scheduler-lib split. These two blueprints are
independent however.
In this blueprint, we need to isolate all accesses to the database that
Scheduler is doing and refactor code (manager, filters,
weighters) so that scheduler is only internally accessing scheduler-related
tables or resources.
Note : this spec is only targeting changes to the Aggregates-related filters.
Problem description
===================
When making decisions involving information about an aggregate, the scheduler
accesses the Nova DB's aggregates table either directly or indirectly via
nova.objects.AggregateList. In order for the split of the scheduler to be
clean, any access by the Nova scheduler to tables that will stay in the Nova DB
(i.e. aggregates table) must be refactored so that the scheduler has an API
method that allows nova-conductor or other services to update the scheduler's
view of aggregate information.
Below is the summary of all filters impacted by that proposal
* AggregateImagePropertiesIsolation,
* AggregateInstanceExtraSpecsFilter,
* AggregateMultiTenancyIsolation,
* AvailabilityZoneFilter,
* AggregateCoreFilter (calls n.objects.aggregate.AggregateList.get_by_host)
* AggregateRamFilter (calls n.objects.aggregate.AggregateList.get_by_host)
* AggregateTypeAffinityFilter (calls
n.objects.aggregate.AggregateList.get_by_host)
Use Cases
----------
N/A, this is a refactoring effort.
Project Priority
-----------------
This blueprint is part of the 'scheduler' refactoring effort identified as a
priority for Kilo.
Proposed change
===============
The strategy will consist in updating the scheduler each time a change comes
to an Aggregate (adding or removing a host or changing metadata).
As the current Scheduler design scales with the number of requests (for each
request, a new HostState object is generated using get_all_host_states method
in the HostManager module), we can't hardly ask the Scheduler to update a DB
each time a new compute comes in an aggregate. It would then create a new
paradigm where the Scheduler would scale with the number of computes added
to aggregates and which could create some race conditions.
Instead, we propose to create an in-memory view of all the aggregates in the
Scheduler which would be populated when the scheduler is starting by calling
the Nova Aggregates API and leave the filters access these objects instead of
calling by themselves the Nova aggregates DB table indirectly.
Updates to the Aggregates which are done using the
``nova.compute.api.AggregateAPI`` will also call the Scheduler RPC API to ask
the Scheduler to update the relevant view.
Alternatives
------------
Obviously, the main concern is about duplicating aggregates information and the
potential race conditions that can occur. In our humble opinion, duplicating
the information in the Scheduler memory is a small price to pay for making sure
that the Scheduler could one day live by its own.
A corollary would be to consider that if duplication is not good, then the
Scheduler should fully *own* the Aggregates table. Consequently, all the calls
in the nova.compute.api.AggregatesAPI would be treated as "external" calls and
once the Scheduler would be splitted out, the Aggregates would no longer reside
in Nova.
Another mid-term approach would be to envisage a second service for the
Scheduler (like nova-scheduler-updater - still very bad at naming...) which
would accept RPC API calls and write the Scheduler DB separatly from the
nova-scheduler service which would actually be treated like a "nova-api"-ish
thing because we could consider that the warmup period for the Scheduler for
populating the relative HostState informations could be problematic and we
could prefer to persist all these objects into the Scheduler DB.
Finally, we definitely are against calling Aggregates API from the Scheduler
each time a filter needs information because it doesn't scale.
Data model impact
-----------------
None, we only create an in-memory object which won't be persisted.
REST API impact
---------------
None
Security impact
---------------
None
Notifications impact
--------------------
None. The atomicity of the operation (adding/modifying an Aggregate) remains
identical, we don't want to add 2 notifications for the same operation.
Other end user impact
---------------------
None
Performance Impact
------------------
Accesses should be done against a memory object instead of accessing the DB,
so we definitely expect better access times and scalability should be improved.
Other deployer impact
---------------------
None
Developer impact
----------------
Ideally:
* Filters should no longer place calls to other bits of code except Scheduler.
This will be done by modifying Scheduler component to proxy conductor calls
to a Singleton which will refuse anything but scheduler-related objects.
See footnote [1] as example. As said above, we will still provide a failback
mode for Kilo release in order to have compatibility with N-1 release.
Implementation
==============
Here, we propose to set the collection of ``nova.objects.Aggregate`` objects
by calling ``nova.objects.AggregateList.get_all()`` during the initialization
of ``nova.scheduler.host_state.HostManager`` as an attribute to HostManager.
In order to access the list of aggregates than an host belongs to, we plan
to add a list of references to the corresponding Aggregate objects as an
extra attribute of ``nova.scheduler.host_state.HostState`` during that
initialization phase.
The second phase would consist to provide updates to that caching system
by amending the Scheduler RPC API by adding a new
update_aggregate() method, which nova.scheduler.client would expose it too.
The update_aggregate() method would take only one argument, a
``nova.objects.Aggregate`` object and would properly update the
``HostManager.aggregates`` attribute so that the ``HostState.aggregates``
reference would implicetely be updated.
Every time that an Aggregate would be updated, we would hook the existing
nova.compute.api.AggregateAPI class and each method in it by adding another
call to nova.scheduler.client which would RPC fanout the call to all
nova-scheduler services.
Once all of that would be done, filters would just have to look into
HostState.aggregates to access all aggregate information (incl. metadata)
related to the aggregates the host belongs to.
Assignee(s)
-----------
Primary assignee:
sylvain-bauza
Other contributors:
None
Work Items
----------
* Instanciate HostManager.aggregates and HostState.aggregates
when scheduler is starting
* Add update_aggregate() method to the Scheduler RPC API and bump a version
* Create nova.scheduler.client method for update_aggregate()
* Modify nova.api.AggregateAPI methods to call the scheduler client method
* Modify filters so they can look to HostState
* Modify scheduler entrypoint to block conductor accesses to Aggregates
(once Lxxx release development will be open)
Dependencies
============
None
Testing
=======
Covered by existing tempest tests and CIs.
Documentation Impact
====================
None
References
==========
* https://etherpad.openstack.org/p/icehouse-external-scheduler
* http://eavesdrop.openstack.org/meetings/gantt/2014/gantt.2014-03-18-15.00.html
[1] http://git.openstack.org/cgit/openstack/nova/commit/?id=e5cbbcfc6a5fa31565d21e6c0ea260faca3b253d

251
specs/kilo/implemented/keypair-x509-certificates.rst Normal file
View File

@@ -0,0 +1,251 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
================================================
Keypair support for X509 public key certificates
================================================
https://blueprints.launchpad.net/nova/+spec/keypair-x509-certificates
Introduction of X509 public key certificates keypair support in the Nova API.
Problem description
===================
Nova keypairs are mostly used by Linux guests to handle user authentication via
SSH public key authentication without incurring in the management and security
overhead that passwords require.
Public keys are provided to the guests as part of the metadata and included in
the guest configuration by tools like cloud-init.
Windows operating systems don't support natively SSH and thus authentication
requires the usage of passwords unless the image deployer chooses to include a
3rd party unsupported SSH service port, which implies incurring in potential
security and support issues.
Windows supports natively password-less authentication for WinRM by using X509
certificates, including PowerShell remoting.
X509 certificates are used by WinRM in a way which can be considered consistent
with the usage of SSH keys on Linux, as both are based on public / private
keypairs. This is limited by the lack of native availability of SSH on Windows.
Certificates can be generated by the user or by Nova (like for the SSH
keypair case). Self-signed certificates are accepted.
Use Cases
----------
End User will be able to connect to a Windows instance without requiring a
password.
Like for the SSH keypair case, the use has the choice to generate the
X509 certificate and pass the public X509 to Nova (recommended) or let Nova
generate and return the certificate including the private key.
Project Priority
-----------------
None
Proposed change
===============
While Nova currently supports SSH keypairs only, the API can be extended to
support x509 certificates, while maintaining full backwards compatibility.
The areas that require changes are:
* Nova API, to accept the certificate type as an option (defaulting to SSH if
not provided)
* The nova.compute.api.KeypairAPI class to be able to generate and manage X509
certificates beside the existing SSH case
* nova.objects.Keypair class to add a type property
* Related database migration
* Nova metadata API to support an additional x509 content in
nova.api.metadata.base.InstanceMetadata()
* python-novaclient to add the optional keypair type option
Usage examples
Generating an x509 keypair via CLI and saving the private certificate locally
(in PKCS#12 format):
nova keypair-add keypair1 --keypair-type x509
Importing an x509 public key certificate:
nova keypair-add keypair1 --keypair-type x509 --pub-key \
/path/to/PEM_encoded_public_certificate
The certificate type could be discovered by examining the content without
requiring the user to provide it explicitly.
For backwards compatibility, omitting the certificate type results in a SSH
certificate:
nova keypair-add keypair2 --pub-key /path/to/SSH_pub_key
equivalent to:
nova keypair-add keypair2 --keypair-type SSH --pub-key /path/to/SSH_pub_key
On the metadata side ssh keys and x509 keys are provided separately for
backwards compatibility:
"public_keys": {"keypair2": "ssh-rsa AAAAB3...cyJvOQ== Generated by Nova\n"},
"x509": {"keypair1": "MIIDaTC...ysk8w==\n"},
Server metadata schema does not need changes:
http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3/server_metadata.py
Alternatives
------------
We are not worrying about the WinRM service certificate, as tools like
cloudbase-init can generate a self signed certificate that works in a similar
way to ssh host keys. Ideally the client would be told what certificate it
needs to trust, but this will be left until we do the same for ssh host keys.
Data model impact
-----------------
nova.objects.Keypair requires an additional string (VARCHAR(20)) type property,
named "Type". Initial possible values will be:
"ssh"
"x509"
Default value during database migration will be "ssh".
REST API impact
---------------
An optional extension named "os-extended-keypairs" will be added to
"/v2/{tenant_id}/os-keypairs" providing the following:
GET /v2/{tenant_id}/os-keypairs
Will include in the response dictionary the key type "key_type".
If the "os-extended-keypairs" extension is not present, only SSH keypairs will
be returned.
POST /v2/{tenant_id}/os-keypairs
Will include an optional parameter "key_type" (xsd:string), with possible
values "SSH" and "X509", default value "SSH".
The keypair schema definition will include "key_type" as well:
::
create = {
'type': 'object',
'properties': {
'keypair': {
'type': 'object',
'properties': {
'name': parameter_types.name,
'public_key': {'type': 'string'},
'key_type': {'type': 'string'},
},
'required': ['name'],
'additionalProperties': False,
},
},
'required': ['keypair'],
'additionalProperties': False,
}
server_create = {
'key_name': parameter_types.name,
}
Security impact
---------------
None
Notifications impact
--------------------
None
Other end user impact
---------------------
None
Performance Impact
------------------
None
Other deployer impact
---------------------
None
Developer impact
----------------
None
Implementation
==============
Assignee(s)
-----------
Primary assignee:
cbelu
Other contributors:
alexpilotti
Work Items
----------
* Nova feature implementation
* python-novaclient support
Dependencies
============
* The guest will need to employ an agent able to retrieve the certificates from
the metadata and import them. Cloudbase-Init >= 0.9.6 is already supporting
x509 certificates.
Testing
=======
* CI testing will be performed by the Hyper-V CI.
* Tempest tests will be developed for this feature.
Documentation Impact
====================
The Nova driver documentation for nova keypair API and CLI commands usage need
to be updated.
References
==========
* Initial discussion (Juno design summit):
https://etherpad.openstack.org/p/nova-hyperv-juno
* Windows authentication without passwords in OpenStack
http://www.cloudbase.it/windows-without-passwords-in-openstack/
* An introduction to WinRM basics
http://blogs.technet.com/b/askperf/archive/2010/09/24/an-introduction-to-winrm-basics.aspx
* Cloudbase-Init on StackForge:
https://github.com/stackforge/cloudbase-init

257
specs/kilo/implemented/libvirt-kvm-systemz.rst Normal file
View File

@@ -0,0 +1,257 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
================================================================
Support KVM/libvirt on System z (S/390) as a hypervisor platform
================================================================
https://blueprints.launchpad.net/nova/+spec/libvirt-kvm-systemz
Add support for KVM/libvirt in Linux on System z as a Nova hypervisor
platform. The existing Nova driver for KVM/libvirt will be used. There are
some platform-specific changes needed in the Nova driver to get the platform
going.
Additional OpenStack functionality beyond initial Nova support is not part of
this blueprint; we will have specific additional blueprints for that, as
needed.
A 3rd party Continuous Integration environment for OpenStack for KVM/libvirt
on System z will be established and maintained.
Problem description
===================
The existing Nova driver for KVM/libvirt does not work unchanged for KVM on
System z.
The issues currently known, are:
1. The System z machine type (``'s390-ccw-virtio'``) needs to be returned by
``LibvirtDriver._get_machine_type()``, if the host architecture is System z.
This then causes the ``os/type/@machine`` attribute in the libvirt
domain.xml to be set up accordingly.
2. The CPU capabilities returned by libvirt on System z do not include the
``model`` element. This is intended to be added to libvirt, but until then
we need a temporary circumvention in the Nova driver (adding the model
information from /proc/cpuinfo if not present and if on S390x).
3. For the interactive console and the log of OpenStack instances, console
devices need to be generated (instead of serial devices), if the host
architecture is System z (see `[2]`_). These console devices need to have a
target type ``"sclp"`` for the interactive console of OpenStack, and
``"sclplm"`` for the log of OpenStack.
Background: Linux on System z writes its messages during its early boot
phases to an interface called "SCLP". SCLP is available in QEMU as a
console device. As a result, it is also a console device in libvirt, with
type="pty" and target type="sclp" for the interactive console of OpenStack,
and with type="file" and target type="sclplm" ("lm" for "line mode") for the
log of OpenStack. If we use the default target type ("virtio"), we will not
capture the messages written by Linux in its early boot phases, and we do
want to provide them.
Changing the default target type for console devices in libvirt to "sclp" or
"sclplm" (e.g. dependent on the ``console/@type`` attribute) would be a
backwards incompatible change of libvirt.
If commonality in the Nova driver across the libvirt platforms is important:
A console device could also be used for other platforms including x86, and
is already used in one of the code paths in the current Nova driver. Serial
devices in libvirt are meant to represent serial ports (aka RS-232), so they
are not an ideal choice anyway, for interactive console and log.
4. The FCP support in the libvirt volume driver needs to be adjusted to
the System z specific format of the device file paths.
In the hypervisor support matrix
(https://wiki.openstack.org/wiki/HypervisorSupportMatrix),
the (new) column for KVM/libvirt on System z is intended to look like the
column for KVM/libvirt on x86, except that the following functions will not be
supported (in addition to those marked as not supported for KVM/libvirt on
x86):
* VNC Console
* SPICE Console
* Inject Networking
For block storage, Cinder will be supported.
For networking, Neutron will be supported. Nova networking should work but will
not be a focus.
As a result, all features marked as required on
https://wiki.openstack.org/wiki/HypervisorSupportMatrix/Requirements
will be supported for KVM/libvirt on System z.
Use Cases
---------
Use OpenStack with KVM on System z
Project Priority
----------------
None
Proposed change
===============
Change code in the libvirt Nova driver to address these issues, dependent on
the host capabilities indicating a CPU architecture of ``arch.S390X``.
For details, see section `Work Items`_.
Alternatives
------------
None
Data model impact
-----------------
None
REST API impact
---------------
None
Security impact
---------------
None
Notifications impact
--------------------
None
Other end user impact
---------------------
None
Performance Impact
------------------
None
Other deployer impact
---------------------
None (no need for platform-specific parameters in nova.conf as part of this
blueprint)
Developer impact
----------------
None (changes should not affect other libvirt platforms)
Implementation
==============
Assignee(s)
-----------
Primary assignee:
mzoeller
Other contributors:
maiera
Work Items
----------
In ``nova/virt/libvirt/driver.py``:
* For issue 1:
In ``LibvirtDriver._get_machine_type()``, return the System z machine type
(``'s390-ccw-virtio'``), if the host architecture is System z.
* For issue 2:
In `` LibvirtDriver._get_host_capabilities()``, add the ``model`` variable
to the capabilities, if not present and if the host architecture is System z;
the model is based on the machine type from /proc/cpuinfo.
* For issue 3:
In ``LibvirtDriver._get_guest_config()``, create console devices instead of
serial devices for the interactive console and for the log, with target type
"sclplm" (for the log) and "sclp" (for the interactive console), if the host
architecture is System z.
In ``nova/virt/libvirt/config.py``:
* For issue 3:
In ``LibvirtConfigGuestChar.__init__()`` and ``format_dom()``, add support
for specifying a target type.
In ``nova/virt/libvirt/volume.py``:
* For issue 4:
The FCP support in the libvirt volume driver needs to be adjusted to
the System z specific format of the device file paths.
In ``nova/virt/libvirt/utils.py``:
* For issue 4:
Possibly, supporting utility functions for the FCP support issue are needed.
Doc changes (see section `Documentation Impact`_).
Dependencies
============
* Software versions:
- Linux kernel: 3.10 or higher
- libvirt: 1.0.4 or higher
- qemu: 1.4.0 or higher
* 3rd party CI environment for KVM/libvirt on System z set up
* Future replacements for temporary circumventions:
- libvirt patch to add model information to CPU capabilities.
Testing
=======
Unit test:
* Existing Nova unit tests should suffice for the generic bits of Nova.
* Additional Nova unit tests for any s390-specific behaviors will be written.
3rd party CI:
* A 3rd party CI environment for KVM/libvirt on Systemz will be set up and run
by by IBM, to run full tempest tests.
Documentation Impact
====================
* No changes needed in config docs.
* Doc changes for the platform will be made as needed (details are to be
determined).
References
==========
* _`[1]` libvirt: Domain XML format, Device Addresses,
http://libvirt.org/formatdomain.html#elementsAddress
* _`[2]` libvirt: Domain XML format, Console,
http://libvirt.org/formatdomain.html#elementCharConsole
* _`[3]` Linux on System z Device Driver book,
http://public.dhe.ibm.com/software/dw/linux390/docu/l316dd25.pdf
* _`[4]` Linux on System z,
http://www.ibm.com/developerworks/linux/linux390/

177
specs/kilo/implemented/libvirt_vif_vhostuser.rst Normal file
View File

@@ -0,0 +1,177 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
============================================
Add VIF_VHOSTUSER vif type to libvirt driver
============================================
https://blueprints.launchpad.net/nova/+spec/libvirt-vif-vhost-user
We propose to add a new VIF type to support the new QEMU vhost-user
interface in libvirt dirver. vhost-user is a new QEMU feature that supports
efficient Virtio-net I/O between a guest and a user-space vswitch.
vhost-user is the userspace equivalent to /dev/vhost-net and is based on
a Unix socket for communication instead of a kernel device file.
Problem description
===================
QEMU has a new type of network interface, vhost-user, and we want to
make this available to Neutron drivers. This will support deploying
high-throughput userspace vswitches for OpenStack-based applications.
There are two types of vSwitches that can use vhost-user
interface, a generic vhost-user vSwitch and ovs based one, both types
should be supported.
Use Cases
---------
This change will allow running userspace vSwitches using vhost-user
interface. Both generic vhost-user vSwitches and OVS based vSwtiches
will be supported.
Project Priority
----------------
No
Proposed change
===============
We propose to add VIF_VHOSTUSER to Nova for creating network
interfaces based on vhost-user. This VIF type would be enabled by
Neutron drivers by using portbindings extension and setting the
vif_type to VIF_VHOSTUSER. To support both generic and ovs based
vSwitches additional information will be passed in vif_details.
For ovs based vSwitches plug/unplug methods will create/remove
an ovs port if 'vhost_user_ovs_plug' is set to True in the vif_details.
VIF_VHOSTUSER driver will allow Neutron mechanism drivers to specify
if qemu should work in server or client mode. Mechanism drivers
could pass 'vhost_user_mode' in vif_details to specify the mode.
The name of the socket will be the same as ID of the Neutron port.
For ovs based vSwitches name of the socket will be the same as name
of the ovs port.
Alternatives
------------
In Juno cycle there were two initiatives to support userspace vhost user
in Nova. One was based on vhost-user interface in Qemu the other was based
on DPDK implementation. Since DPDK is moving to support vhost-user only one
driver is needed.
Alternatively a mechanism for plugging in vif libvirt driver could be used
to support
vhost-user in libvirt driver. Such mechanism is proposed here:
https://blueprints.launchpad.net/nova/+spec/libvirt-vif-driver-plugin
Data model impact
-----------------
None.
REST API impact
---------------
None.
Security impact
---------------
None.
Notifications impact
--------------------
None.
Other end user impact
---------------------
None.
Performance Impact
------------------
Use of VIF_VHOSTUSER will have no inpact on Openstack performance.
Use of userspace vSwitch with vhost-user will improve guest network perforamce.
Other deployer impact
---------------------
VIF_VHOSTUSER does not have to be enabled by the deployer. Neutron
drivers will automatically enable VIF_VHOSTUSER via port binding if
this is the appropriate choice for the agent on the compute host.
VIF_VHOSTUSER will require a version of QEMU with vhost-user support,
which is currently upstream and will be released in QEMU 2.1.
VIF_VHOSTUSER will also require a version of Libvirt with vhost-user
support.
Developer impact
----------------
None.
Implementation
==============
Assignee(s)
-----------
Primary assignee:
Przemyslaw Czesnowicz <pczesno>
Work Items
----------
* Add VIF_VHOSTUSER support to Nova.
Dependencies
============
An ml2 dpdk ovs driver is being proposed for Neutron.
This feature doesn't directly depend on it.
This feature depends on bp/virt-driver-large-pages.
Testing
=======
VIF_VHOSTUSER will be tested by 3rd party CI for the DPDK Ovs mech driver.
Documentation Impact
====================
No documentation changes for Nova are anticipated. VIF_VHOSTUSER will
be automatically enabled by Neutron where appropriate.
References
==========
* vhost-user:
http://www.virtualopensystems.com/en/solutions/guides/snabbswitch-qemu/
* Snabb NFV (initial vswitch supporting vhost-user): http://snabb.co/nfv.html
* Juno spec for VIF_VHOSTUSER:
https://review.openstack.org/#/c/96138/
* Juno spec for dpdkvhost
https://review.openstack.org/#/c/95805/4/specs/juno/libvirt-ovs-use-usvhost.rst
* Neutron dpdk-ovs mechanism driver
https://blueprints.launchpad.net/neutron/+spec/ml2-dpdk-ovs-mechanism-driver
* Blueprint for vif plugin mechanism.
https://blueprints.launchpad.net/nova/+spec/libvirt-vif-driver-plugin
* Blueprint for Hugepage support
https://blueprints.launchpad.net/nova/+spec/virt-driver-large-pages

155
specs/kilo/implemented/opencontrail-nova-vif-plugin.rst Normal file
View File

@@ -0,0 +1,155 @@
==========================================
Nova Plugin for OpenContrail
==========================================
https://blueprints.launchpad.net/nova/+spec/opencontrail-nova-vif-driver-plugin
This blueprint is to add plugin for OpenContrail in existing Nova
VIF driver to support OpenContrail based network virtualization
for Openstack.
The OpenContrail APIs will cover following:
* Create Interface
* Delete Interface
* Get Interface Config
Problem description
===================
OpenContrail is open source network virtualization solution. It uses standards
based BGP L3VPN closed user groups to implement virtual networks.
The link http://OpenContrail.org/OpenContrail-architecture-documentation/
explains the architecture of OpenContrail plugin
OpenContrail plugin get merged to neutron on Juno timeframe.
OpenContrail is loading its VIF driver via openstack-config command
using option libvirt_vif_driver. In Juno this option is no longer supported
and same needs to be implemented under Nova VIF driver.
Use Cases
---------
Use Nova with Neutron + OpenContrail
For more details, please take a look this link
http://www.opencontrail.org/opencontrail-architecture-documentation/#section1_1
Project Priority
----------------
Not applicable
Proposed change
===============
Add OpenContrail APIs to handle the Creation/Deletion/Get of
interfaces in Nova VIF driver. There are no changes to the Nova common code.
Alternatives
------------
None.
Data model impact
-----------------
None.
REST API impact
---------------
None.
There are no new API added to Nova. For above listed API all features
will be supported by the plugin.
Security impact
---------------
The communication channel to the backend is not secure.
We will support secure channel in the future.
Notifications impact
--------------------
None.
Other end user impact
---------------------
None.
Performance Impact
------------------
None.
Other deployer impact
---------------------
None.
Developer impact
----------------
None.
Other Developers wont be effected by this change.
Implementation
==============
Model - VIF_TYPE_VROUTER
Following APIs will be implemented:
def get_config_vrouter(self, instance, vif, image_meta, inst_type, virt_type)
def plug_vrouter(self, instance, vif)
def unplug_vrouter(self, instance, vif)
Assignee(s)
-----------
Primary assignee:
manishs
Other contributors:
hajay
Work Items
----------
1. OpenContrail API implementation
2. OpenContrail mocks for unit-tests
Dependencies
============
None.
Testing
=======
Existing and new Nova unit tests will be used.
Existing and new tempest testing for Nova will be used.
Documentation Impact
====================
None.
The link below explains setup of OpenContrail using devstack.
http://pedrormarques.wordpress.com/2013/11/14/using-devstack-plus-OpenContrail/
References
==========
http://www.OpenContrail.org
https://github.com/Juniper/contrail-controller

150
specs/kilo/implemented/pass-flavor-capabilities-to-ironic-virt-driver.rst Normal file
View File

@@ -0,0 +1,150 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
=====================================================
Pass on the capabilities in the flavor to the ironic
=====================================================
https://blueprints.launchpad.net/nova/+spec/pass-flavor-capabilities-to-ironic-virt-driver
Today nova doesn't pass on the `capabilities` defined in `extra-spec`
key of the flavor. The ironic needs to be aware of the requested
capability in the flavor.
Problem description
===================
Today nova doesn't pass on the `capabilities` defined in `extra-spec`
key of the flavor. Today Nova is able to read the capabilities
defined in the ironic node's properties field and select the node
using the ComputeCapabilities Filter. Now, the ironic needs to be aware
of the requested capability in the flavor so that it can take specific
actions as per the request in the flavor once the node has been scheduled
by Nova.
Use Cases
----------
The ironic can use it for following:
1. Prepare the node in the desired state before deploy.
2. The same can be used during decommisioning the node for unwinding to its
original state.
Example: say a capability as, `power_optimized=True` as given in
flavor-key. The ironic has node.properties updated with capability as
`power_optimzied=True`. The node is selected via
ComputeCapabilities Filter. Now, if the node's instance_info is updated
by nova as `power_optimzied=True`, the ironic driver can prepare the
node in desired power state.
This is applicable for all the hardware capabilities which requires
some action from the driver as per the requested capability in the
flavor extra-spec key.
Project Priority
-----------------
None.
Proposed change
===============
The proposal is to update the instance_info field of the node object with
the capabilities defined in the flavor extra-spec.
Alternatives
------------
Ironic can in fact look this information up by calling the Nova API. However,
that would require Ironic to have sufficient permissions to see the flavor,
and would add a Keystone round trip for Ironic to fetch an authentication
token. Nova already passes a lot of meta data through in a boot request, so
avoiding the extra round trip seems worthwhile.
Data model impact
-----------------
None.
REST API impact
---------------
None.
Security impact
---------------
None.
Notifications impact
--------------------
None.
Other end user impact
---------------------
None.
Performance Impact
------------------
None.
Other deployer impact
---------------------
This change takes immediate effect once the ironic is supported for
hardware capabilities which is a work-in-progress for kilo in ironic.
Developer impact
----------------
None.
Implementation
==============
See Work Items below.
Assignee(s)
-----------
Primary assignee:
agarwalnisha1980
Work Items
----------
* Require changes in nova/virt/ironic/patcher.py to update the instance_info
field with the flavor capabilities.
Dependencies
============
None.
Testing
=======
Unit tests will be added.
Documentation Impact
====================
This will be documented under ironic.
References
==========
Exposing Hardware capabilities:
https://review.openstack.org/#/c/131272/
https://etherpad.openstack.org/p/kilo-ironic-exposing-different-capabilities
For supporting multiple values with `capabilities`:
https://review.openstack.org/133534

252
specs/kilo/implemented/pcs-support.rst Normal file
View File

@@ -0,0 +1,252 @@
=====================================================
Parallels Cloud Server support in nova/libvirt driver
=====================================================
https://blueprints.launchpad.net/nova/+spec/pcs-support
This specification is intended to describe process of extending nova/libvirt
driver in order to support Parallels Cloud Server [1]_
Problem description
===================
Parallels Cloud Server (PCS) is a virtualization solution product, which
enables service providers to use container and hypervisor virtualization
technology via the same management tools and API.
Though PCS is supported by libvirt it is absent in OpenStack for now due to
not only specific demand related to compute node deployment but also
different disk image format implied by usage of Parallels disk loopback block
device [2]_, domains configuration and supported features.
Use Cases
----------
This change will allow those service providers that use PCS as their
primary virtualization solution to build a cloud upon it using OpenStack.
There is no impact on users who aren't engaged with PCS.
Project Priority
-----------------
No priority defined for this feature yet.
Proposed change
===============
To make PCS be supported by OpenStack we need to modify nova/libvirt driver
mostly regarding a new type of virtualization processing.
The end user will be able to configure nova to use PCS by setting
libvirt.virt_type option to "parallels". Also, as a native disk format for
both VMs and containers supported in PCS is ploop [2]_, to get best performance
we will need to change glance-api configuration to support PCS ploop format.
Using images of different formats will be provided by in-place convertion.
As each host reports supported instances via the resource tracker and
the 'vm_mode' property of images is used to determine what kind of
virtualization to run an a particular host, a decision about it will be made
on an image with particular vm_mode property (eg vm_mode=exe to run containers
or vm_mode=hvm to run hypervisor based instances). So PCS hosts will support
arbitrary mix of machine and container based guests.
In case a cloud administrator needs a way to partition hosts into groups so
that some hosts exclusively run machine virt, while other hosts exclusively
run container virt, host aggregates and flavours extra specs should be used.
nova.conf extract example:
[libvirt]
...
virt_type = parallels
images_type = ploop
...
glance-api.conf extract example:
...
disk_formats=ami,ari,aki,vhd,vmdk,raw,qcow2,vdi,iso,ploop
...
Here is a list of of features we plan to support:
+-----------------------+------+-------------+
| | VMs | Containers |
+=======================+======+=============+
| Launch | yes | yes |
+-----------------------+------+-------------+
| Reboot | yes | yes |
+-----------------------+------+-------------+
| Terminate | yes | yes |
+-----------------------+------+-------------+
| Resize | yes | yes |
+-----------------------+------+-------------+
| Rescue | yes | yes |
+-----------------------+------+-------------+
| Pause | yes | (1) |
+-----------------------+------+-------------+
| Un-pause | yes | (1) |
+-----------------------+------+-------------+
| Suspend | yes | yes |
+-----------------------+------+-------------+
| Resume | yes | yes |
+-----------------------+------+-------------+
| Inject Networking | yes | yes |
+-----------------------+------+-------------+
| Inject File | yes | yes |
+-----------------------+------+-------------+
| Serial Console Output | yes | no |
+-----------------------+------+-------------+
| VNC Console | yes | yes |
+-----------------------+------+-------------+
| SPICE Console | no | no |
+-----------------------+------+-------------+
| RDP Console | no | no |
+-----------------------+------+-------------+
| Attach Volume | yes | (2) |
+-----------------------+------+-------------+
| Detach Volume | yes | (2) |
+-----------------------+------+-------------+
| Live Migration | yes | yes |
+-----------------------+------+-------------+
| Snapshot | yes | yes |
+-----------------------+------+-------------+
| iSCSI | yes | yes |
+-----------------------+------+-------------+
| iSCSI CHAP | yes | yes |
+-----------------------+------+-------------+
| Fibre Channel | yes | yes |
+-----------------------+------+-------------+
| Set Admin Pass | yes | yes |
+-----------------------+------+-------------+
| Get Guest Info | yes | yes |
+-----------------------+------+-------------+
| Glance Integration | yes | yes |
+-----------------------+------+-------------+
| Service Control | no | yes |
+-----------------------+------+-------------+
| VLAN Networking | yes | yes |
+-----------------------+------+-------------+
| Flat Networking | yes | yes |
+-----------------------+------+-------------+
| Security Groups | yes | yes |
+-----------------------+------+-------------+
| Firewall Rules | yes | yes |
+-----------------------+------+-------------+
| nova diagnostics | no | no |
+-----------------------+------+-------------+
| Config Drive | yes | yes |
+-----------------------+------+-------------+
| Auto configure disk | no | yes |
+-----------------------+------+-------------+
| Evacuate | yes | yes |
+-----------------------+------+-------------+
| Volume swap | yes | (3) |
+-----------------------+------+-------------+
| Volume rate limiting | (4) | (4) |
+-----------------------+------+-------------+
(1) There are no technical problems with pausing containers it's
not implemented by now.
(2) It's possible to attach volume to a container either as a block device or
as a mount point, giving both types of access simultaneously has a
security problem.
(3) We can tune swap size in containers with vswap technology [4]_,
not as a conventional swap disk.
(4) We can tune IO rate only for the whole instance but
not for individual volumes.
Alternatives
------------
The alternate way is to implement a separate PCS nova driver like this [3]_,
which was implemented in terms of PCS + OpenStack proof of concept.
pros:
* There is no middle layer between OpenStack and PCS as pcs-nova-driver uses
native PCS's python API.
* Changes in pcs-nova-driver will not affect nova/libvirt's code.
cons:
* Yet another nova driver
* It is out-of-tree driver
Data model impact
-----------------
None.
REST API impact
---------------
None.
Security impact
---------------
None.
Notifications impact
--------------------
None.
Other end user impact
---------------------
None.
Performance Impact
------------------
None.
Other deployer impact
---------------------
Compute nodes available for "parallels" type of virtualization have to be
deployed in advance. Integrating PCS hosts deployment with OpenStack is out
of this spec scope.
Developer impact
----------------
None.
Implementation
==============
Assignee(s)
-----------
Primary assignee:
dguryanov
Other contributors:
burluka
mnestratov
Work Items
----------
* Enhance libvirt driver to support new virt_type value.
* Implement all the functionality necessary to support PCS in libvirt driver
Dependencies
============
Add support of new disk image format in glance
Bluesprint https://blueprints.launchpad.net/glance/+spec/pcs-support
None
Testing
=======
Testing in the gate will be provided by currently being established Parallels
CI testing system.
Documentation Impact
====================
New type of virtualization provider should be noticed and host deployment
pre-requisites such as the need to have PCS installed on compute nodes.
References
==========
.. [1] Parallels Cloud Server http://www.parallels.com/products/pcs
.. [2] Ploop block device http://openvz.org/Ploop
.. [3] PCS nova driver https://github.com/parallels/pcs-nova-driver
.. [4] OpenVZ kernel memory management model https://openvz.org/VSwap

170
specs/kilo/implemented/qemu-built-in-iscsi-initiator.rst Normal file
View File

@@ -0,0 +1,170 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
=============================================
Add support for QEMU built-in iSCSI initiator
=============================================
https://blueprints.launchpad.net/nova/+spec/qemu-built-in-iscsi-initiator
QEMU has built-in iSCSI initiator using libiscsi and Libvirt can handle it as
same as other network storages. This blueprint adds iSCSI support to Nova's
network volume driver (nova.virt.libvirt.LibvirtNetVolumeDriver).
Problem description
===================
Nova already has iSCSI volume driver for KVM/QEMU
(nova.virt.libvirt.LibvirtISCSIVolumeDriver), but iSCSI targets for volumes
aren't attached to VMs directly but to the host OS of nova-compute nodes. It
means:
* Storage structure of the host OS will be changed when volumes are attaching
to / detaching from VMs on the host. The commands executed by nova-compute to
attach/detach volumes are complex. So they may cause confusing storage
structure the host OS and make trouble shooting difficult when a problem had
occured.
* The host OS have many system logs on attaching/detaching volumes and tons of
error logs if a trouble occurs at the iSCSI target or multipath.
* The VMs on a compute node will be stopped when an iSCSI volume is attached or
detached to a VM and it causes the host OS crash.
Use Cases
----------
* Using so many iSCSI-based volumes and attached them to many VMs on a host.
Say that up to 50 VMs on a host and up to 20 volumes attached to a VM. It
means that the host OS will handle up to 1k iSCSI targets by itself with
LibvirtISCSIVpolumeDriver and the number will be 2x, 3x, or 4x if you use
iSCSI multipath capability.
Project Priority
-----------------
None
Proposed change
===============
Using KVM/QEMU built-in iSCSI initiator via Libvirt for attaching iSCSI
volumes. To do so, we have to implement 2 functionality:
* Implement a new libvirt XML configuration handler class named
LibvirtConfigSecret. It manages information for iSCSI CHAP authentication.
* Extend LibvirtNetVolumeDriver to support QEMU built-in iSCSI initiator using
LibvirtConfigSecret if needed.
Alternatives
------------
Just use LibvirtISCSIVolumeDriver.
Data model impact
-----------------
None
REST API impact
---------------
None
Security impact
---------------
None
Notifications impact
--------------------
None
Other end user impact
---------------------
None
Performance Impact
------------------
None
Other deployer impact
---------------------
* QEMU built-in iSCSI initiator doesn't support multipath capability. So VMs
will be not able to handle volumes when iSCSI connections die even if the
backend iSCSI storage has multipath capability.
* QEMU binary of Ubuntu 14.04 doesn't have iSCSI support. Users have to install
libiscsi2 package and libiscsi-dev from Debian and rebuild QEMU binary
with libiscsi support by themselves.
Developer impact
----------------
None
Implementation
==============
Assignee(s)
-----------
Primary assignee:
Akira Yoshiyama <akirayoshiyama@gmail.com>
Work Items
----------
Working patches exist, so we have to:
* Implement unit tests.
* Review the codes.
Dependencies
============
None
Testing
=======
Usually, devstack builds an OpenStack deployment with Cinder using
LVMISCSIDriver, so we can use it for basic smoke tests. And we should do more
tests with vendor iSCSI drivers.
Documentation Impact
====================
Adding configuration notes to use the driver like below:
To use this, you have to write a parameter at nova.conf:
volume_drivers = iscsi=nova.virt.libvirt.volume.LibvirtNetVolumeDriver,
iser=nova.virt.libvirt.volume.LibvirtISERVolumeDriver,...
or just
volume_drivers = iscsi=nova.virt.libvirt.volume.LibvirtNetVolumeDriver
References
==========
* Libvirt Secret XML format:
http://libvirt.org/formatsecret.html
* Libvirt Domain XML format: Hard drives, floppy disks, CDROMs
http://libvirt.org/formatdomain.html#elementsDisks

161
specs/kilo/implemented/quiesced-image-snapshots-with-qemu-guest-agent.rst Normal file
View File

@@ -0,0 +1,161 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
=====================================================================
Quiescing filesystems with QEMU guest agent during image snapshotting
=====================================================================
https://blueprints.launchpad.net/nova/+spec/quiesced-image-snapshots-with-qemu-guest-agent
When QEMU Guest Agent is installed in a kvm instance, we can request the
instance to freeze filesystems via libvirt during snapshotting to make the
snapshot consistent.
Problem description
===================
Currently we need to quiesce filesystems (fsfreeze) manually before
snapshotting an image of active instances to create consistent backups.
This should be automated when QEMU Guest Agent is enabled.
(Quiescing on cinder's create-snapshot API is covered by another proposal [1]_)
Use Cases
---------
With this feature, users can create a snapshot image with consistent
file systems state while the instances are running (fsck will not run when
the snapshot image is booted).
It will be nice when:
* taking a quick backup before installing or upgrading softwares.
* automatically taking backup images every night.
Project Priority
----------------
None
Proposed change
===============
When QEMU Guest Agent is enabled in an instance, Nova-compute libvirt driver
will request the agent to freeze the filesystems (and applications if
fsfreeze-hook is installed) before taking snapshot of the image.
For boot-from-volume instances, Nova will call Cinder's snapshot-create API
for every volume attached after quiescing an instance. To avoid double
quiescing, Nova should tell Cinder not to quiesce the instance on snapshot.
For this purpose, 'quiesce=True|False' parameter will be added to
Cinder's snapshot-create API.
After taking snapshots, the driver will request the agent to thaw the
filesystems.
The prerequisites of this feature are:
1. the hypervisor is 'qemu' or 'kvm'
2. libvirt >= 1.2.5 (which has fsFreeze/fsThaw API) is installed in the
hypervisor
3. 'hw_qemu_guest_agent=yes' property and 'hw_require_fsfreeze=yes' property
is set on the image metadata,
and QEMU Guest Agent is installed and enabled in the instance
When quiesce is failed even though these conditions are satisfied
(e.g. the agent is not responding), snapshotting may fail by exception
not to get inconsistent snapshots.
Alternatives
------------
Rewrite nova's snapshotting with libvirt's domain.createSnapshot API with
VIR_DOMAIN_SNAPSHOT_CREATE_QUIESCE flag, although it will change the current
naming scheme of disk images. In addition, it cannot be leveraged to implement
live snapshot of cinder volumes.
Data model impact
-----------------
None
REST API impact
---------------
None
Security impact
---------------
None
Notifications impact
--------------------
None
Other end user impact
---------------------
None
Performance Impact
------------------
While taking snapshots, disk writes from the instance are blocked.
Other deployer impact
---------------------
None
Developer impact
----------------
None
Implementation
==============
Assignee(s)
-----------
Primary assignee:
tsekiyama
Work Items
----------
1. Implement the automatic quiesce during snapshotting when it is available.
2. Add a quiesced snapshotting scenario test with libvirt >= 1.2.5
(Fedora experimental queue will be a good place to start testing.)
Dependencies
============
None
Testing
=======
Live snapshotting with an image with qemu-guest-agent should be added to
tempest.
Note that it requires environment with libvirt >= 1.2.5, so it would be
Fedora experimental queue job with virt-preview repository enabled.
Documentation Impact
====================
Need to document how to use this feature in the operation guide (which
currently recommends you use the fsfreeze tool manually).
References
==========
.. [1] Quiesce admin action for consistent snapshot:
https://review.openstack.org/#/c/128112/

157
specs/kilo/implemented/quobyte-nova-driver.rst Normal file
View File

@@ -0,0 +1,157 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
==========================================
Add a Quobyte Volume Driver in Nova
==========================================
https://blueprints.launchpad.net/nova/+spec/quobyte-nova-driver
Add a Nova volume driver for the `Quobyte Unified Storage Plane
<http://quobyte.com/>`_ storage system, allowing to attach vm images residing
in Quobyte USP to Nova instances. These images (raw, qcow2) are stored as
files on a Quobyte USP volume.
Problem description
===================
The Quobyte USP provides flexible access to file based storage. Nova can
currently not attach Quobyte USP volumes, although a `Cinder driver
<https://blueprints.launchpad.net/cinder/+spec/quobyte-usp- driver>`_ is
currently in preparation.
Use Cases
----------
Operators can deploy Quobyte USP storage for their Nova installations.
Project Priority
-----------------
None
Proposed change
===============
Add support for the `Quobyte Unified Storage Plane <http://quobyte.com/>`_
to nova.virt.libvirt.volume.py by adding a new class
LibvirtQuobyteVolumeDriver based on the LibvirtBaseVolumeDriver. Code
structure will be similiar to the GlusterFS class
LibvirtGlusterfsVolumeDriver. The Driver will check mountpoint availability,
run mountpoint preparations if required and mount the given Quobyte USP volume
based on the configuration data (connection_info, etc.). Based on the local
qemu 2.0.0+ availability the driver optimizes performance by adopting matching
caching strategies. Other functionalities include volume disconnect (i.e.
unmounting the Quobyte USP volume) and configuration data provisioning
(get_config).
Alternatives
------------
None
Data model impact
-----------------
None
REST API impact
---------------
None
Security impact
---------------
None
Notifications impact
--------------------
None
Other end user impact
---------------------
None
Performance Impact
------------------
None
Other deployer impact
---------------------
Quobyte USP specific config options are
* quobyte_mount_point_base (Directory where the Quobyte volume is
mounted on the compute node)
* quobyte_client_cfg (Path to a Quobyte Client configuration file)
Mounting Quobyte USP volumes is done as Nova user, not as root. The Nova user
needs to be FUSE enabled, e.g. a member of the fuse group. The deployer has to
install the Quobyte USP software.
Developer impact
----------------
None
Implementation
==============
Assignee(s)
-----------
Primary assignee:
<silvan@quobyte.com>
Other contributors:
<mberlin@quobyte.com>
Work Items
----------
Implementation has been done and tested via Tempest.
The code can be found at `Change-Id:
Ica1820031f1fc8b66d7ed7fe76ffeb985cf0ef35
<https://review.openstack.org/#/c/110722/>`_.
Dependencies
============
This change requires the corresponding `Cinder driver
<https://blueprints.launchpad.net/cinder/+spec/quobyte-usp-driver>`_ is
required, the respective code can be found at `Change-Id:
I7ca13e28b000d7a07c2baecd5454e50be4c9640b
<https://review.openstack.org/#/c/94186/>`_.
Testing
=======
Currently no additional Tempest tests are required as the existing tests and
test scenarios cover the volume usage functionalities provided by the driver.
For the corresponding Cinder driver a 3rd party CI is in preparation that will
also test the Nova driver. Unit tests have been created in conjunction with
the existing driver code.
Documentation Impact
====================
None
References
==========
None

214
specs/kilo/implemented/support-other-iscsi-transports-besides-tcp.rst Normal file
View File

@@ -0,0 +1,214 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
====================================================================
Refactor ISCSIDriver to support other iSCSI transports besides TCP
====================================================================
https://blueprints.launchpad.net/nova/+spec/add-open-iscsi-transport-support
Currently open-iscsi in openstack does not allow the use of offload iscsi
transports (cxgb4i, qla4xx, bnx2i etc) or other software iscsi transports
(like iser). This blueprint aims to add support for this
Problem description
===================
open-iscsi has hardware iSCSI transport support. The interface argument
specifies the hardware iSCSI interface to use for the operation. Any hardware
vendors that currently provide hardware interfaces for open-iscsi cannot use
them in openstack as the interfaces (iface) argument is not currently
supported in the iSCSI driver.
While this effort is being done by Chelsio, the approach is currently to make
it generic enough for all supported HBAs (Host Bus Adapter).
Use of such iSCSI hardware transports requires providing a corresponding
interface file (referred to as iface), which can be autogenerated via iscsiadm
but need correctness checks or can also be generated on the fly, given the
3-tuple of ipaddress, hwaddress & transport name to be used. The iface format
itself is generic and does not use any propreitary fields irrespective of
transport being used.
This also addresses a second problem with the current transport support in
nova, namely the iSER driver. It is currently a full copy of the normal
open-iscsi driver code with an extra parameter setting transport to 'iser'
This will also enable use of iSER directly through the iSCSI driver, though
deprecating the iSER driver is not the aim of this spec, and will probably
start with iSER disabled, (and also because iSER requires target support
unlike hardware transports) Previous relevant specs are here :
https://review.openstack.org/#/c/86637/
https://blueprints.launchpad.net/nova/+spec/add-transport-support-to-iscsi
https://blueprints.launchpad.net/cinder/+spec/add-transport-support-to-iscsi
A follow up blueprint is expected to deprecate the separate iSER driver
and just roll functionality into using transport support.
Use Cases
----------
User has an HBA that supports hardware iSCSI installed in his system. Using
open-iscsi's hardware transport support allows for iSCSI communication at
higher speeds and reduced CPU usage.
Current transports supported by open-iscsi are :
* Chelsio : cxgb3i, cxgb4i
* QLogic : qla4xxx, bnx2i (formerly Broadcom)
* Emulex : be2iscsi, ocs
* Mellanox & others : iser
Use of any of these transports requires the appropriate hardware to be present
in the system, but iSER will not be supported at the very start.
Project Priority
-----------------
None
Proposed change
===============
On the initiator side the only difference between using software iSCSI and
hardware iSCSI transport is the interface flag (--interface=[iface])
e.g. "iscsiadm -m discovery -t st -p ip:port -I <iface file>"
iface files can automatically be generated for all hardware present on a
system that is supported by open-iscsi by 'iscsiadm -m iface'. The default
format for iface file names is in the form <transport_name.hw_address>
The default iface name is 'default'. Not using the -I parameter (which is how
open-iscsi is currently being used in nova) is the same as specifying
'iscsiadm -m discovery -t st -p ip:port -I default'
Required changes are :
* A new parameter to specify which transport should be used while doing iscsi
discovery/login, falling back to TCP if operation does not succeed, or if
parameter is not provided (-I default)
* An alternative (but lot more complicated ) approach might be to figure out
iface name from source ip address. ipaddress can be used to figure out
hwaddress and pci dev id. pci dev id provides transport name, iface names
are in the format <transportname>.<hwaddress>
* Optional/unresearched : Further down the line, it might make sense to see
if networking services can be integrated to provide a networking interface
for open-iscsi transports, but its out of the scope of this spec.
Other related changes :
* Verify hardware exists before attempting to use said transport. The best
way to accomplish this is checking PCI vendor ids/MAC address if nova would
be open to accepting such code.
Alternatives
------------
Use manual discovery of iscsi-targets, and provide -I parameter when doing
discovery. Transport names are written in the resultant records generated by
open-iscsi, however this does not guarantee hardware transports will be used,
as this can be overridden with depending on how cli params are constructed.
Data model impact
-----------------
None
REST API impact
---------------
None
Security impact
---------------
None
Notifications impact
--------------------
None
Other end user impact
---------------------
Performance Impact
------------------
iSCSI performance is improved drastically, no extra commands are added to
driver, except perhaps one to generate the default iface files :
'iscsiadm -m iface'
Other deployer impact
---------------------
This can be used as a stepping stone to eventually replace & deprecate
LibvirtISERVolumeDriver as 'iscsiadm -I iser' can be used for iSER support
without requiring a separate driver.
Developer impact
----------------
None
Implementation
==============
Assignee(s)
-----------
Primary assignee:
anish7 <anish@chelsio.com>
iSER driver deprecation & followup spec Assignee :
aviramb <aviramb@mellanox.com>
nuritv <nuritv@mellanox.com>
Work Items
----------
* Add -I parameter to all iscsiadm login/discovery commands in
'nova/virt/libvirt/volume.py'
* Add transport parameter to config options, which defaults to software iscsi
i.e. '-I default'
Dependencies
============
None as such. However, the minimum information required for using a tansport
if it is not already configured is a 3 tuple of ip, transport name & hardware
address. Functionality to this effect would be good to have for automatic
configuration of transports.
Testing
=======
Current iSCSI tests will work just fine. Will be testing on Chelsio hardware,
and any other transport supporting hardware that can be obtained.
Documentation Impact
====================
New transport parameter will need relevant documentation.
References
==========
* http://www.open-iscsi.org/docs/README (Section 5.1 iSCSI iface setup)
* http://red.ht/1BJxsjL (Configuring an iface for iSCSI Offload, RedHat documentation)

277
specs/kilo/implemented/v2-on-v3-api.rst Normal file
View File

@@ -0,0 +1,277 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
=============================================
Implement the v2.1 API on the V3 API codebase
=============================================
https://blueprints.launchpad.net/nova/+spec/v2-on-v3-api
Implement v2 compatible API based on v3 API infrastructure.
Problem description
===================
On v3 API development, we have improved API infrastructure such as API
plugin loading, input validation, policy check, etc. In addition, to fix
inconsistent interfaces of v2 API, we have made a significant number of
backwards incompatible changes of the Nova API (Change success status
codes, API attribute names, and API URLs). There is a comprehensive
description of the problems with the v2 API for users, operators and
developers here:
http://ozlabs.org/~cyeoh/V3_API.html
However, there have been intensive discussions over the future of Nova
and the maintenance overhead implications from having to support two
APIs such as v2 and v3 simultaneously for a long period of time.
Use Cases
---------
This is primarily API infrastructure cleanup work which will
eventually allow us developers to remove the old V2 API codebase which
is fragile and does not support the features of the V3 API
framework. It also is required work in order to support microversions
in the future. The impact on users and deployers is described in the
following sections.
Project Priority
-----------------
The kilo priorities list is currently not defined. However under the
currently proposed list of priorities it would fall under "User
Experience" as it paves the way for microversions and the ability for
us to improve the Nova API.
Proposed change
===============
Through a lot of discussions, we have understood the advantages of v3 API
infrastructure (API plugin loading, input validation, policy check, etc).
However, their backwards incompatible interfaces seem a little premature at
this time, because now we aren't sure that current v3 API is the best.
That means we cannot be sure that any more backwards incompatible changes
are unnecessary even if switching to current v3 API.
This spec proposes the removal of backwards incompatible changes from v3 code.
That means current v3 consistent interfaces would go back to v2 inconsistent
ones like::
--- a/nova/api/openstack/compute/plugins/v3/servers.py
+++ b/nova/api/openstack/compute/plugins/v3/servers.py
@@ -752,7 +752,7 @@ class ServersController(wsgi.Controller):
The field image_ref is mandatory when no block devices have been
defined and must be a proper uuid when present.
"""
- image_href = server_dict.get('image_ref')
+ image_href = server_dict.get('imageRef')
This proposal is painful for v3 API developers because they have worked hard
to make consistent interfaces over a year and v3 interfaces are exactly better
than v2 ones. However, through the discussions, we have known that backwards
incompatible changes are very painful for users and we must pay attention to
these changes.
On this spec, we would provide v2 compatible API with the other v3 advantages
as the first step. After this spec, we will provide consistent interfaces by
defining API rules step by step. These rules will prevent the same backwards
incompatible changes and keep consistent interfaces even if adding a lot of
new APIs in the future. However, that is out of scope from this spec now.
Alternatives
------------
Through these discussions, we got an idea that we could support both v2 API
and v3 API on the top of the v3 API codebase. On this idea, nova translates a
v2 request to v3 request and passes it to v3 API method. After v3 API method
operation, nova translates its v3 response to v2 response again and returns
it to a client.
However, there was an intensive discussion against this idea also because it
would be difficult to debug API problems due to many translations when we have
a lot of backwards incompatible changes in the long term.
Data model impact
-----------------
None
REST API impact
---------------
The V2.1 REST API presented will be identical to the V2 API except as
noted above.
Note however that V2.1 will not support the XML version of the V2 API,
only the JSON one. However the XML version of the V2 API is currently
marked as deprecated.
Security impact
---------------
Better up front input validation will reduce the ability for malicious
user input to exploit security bugs.
Notifications impact
--------------------
None
Other end user impact
---------------------
Potentially it may be advantageous if python novaclient could talk to
/v2.1 instead of /v2 but code changes may not be required to change
this. It may be simpler just to do this through keystone configuration.
The API itself remains identical.
Performance Impact
------------------
More stringent input validation also means more work that is needed to
be done in the API layer but overall this is a good thing.
Other deployer impact
---------------------
If the deployer wanted to export the API as /v2 rather than /v2.1 then
they would need to modify the api-paste.ini file (a couple of line
change to disable the original V2 API and use the APIRouterV21 as
the /v2 API.
The long term goal would be to deprecate and eventually remove the
original V2 API code when deployers and users are satisfied that v2.1
satisfies their requirements.
The process which we would use is:
* V2.1 fully implemented with Tempest verification (including extra
verification that is being added in terms of response data)
* Verification from multiple sources (cloud providers, users etc) that
V2.1 is compatible with V2
* This could be done in various ways
* Keystone changes so /v2.1 is advertised instead of /v2
* Exporting the V2.1 as /v2
* Combined with the possibility of putting V2.1 input validation into
a log rather than reject mode.
* V2.1 is in an openstack release for N versions
* After widespread confirmation that the V2.1 API is compatible, V2
would be marked as deprecated
Developer impact
----------------
Long term advantages for developers are:
* All the API implementations are on the new API framework
* Reduction in maintenance overhead of supporting two major API
versions
* Have a better framework for handling future backwards incompatible
changes.
In the short term while the old V2 API code exists there will still be
a dual maintenance overhead.
Implementation
==============
Assignee(s)
-----------
Primary assignee:
cyeoh-0
Other contributors:
oomichi
Alex Xu
Work Items
----------
* Change v3 success status codes to v2 ones.
* Change v3 API routings to v2 ones.
* Handle API URLs include a project id.
* Change the API resource paths. (e.g: /keypairs(v3) -> /os-keypairs(v2))
* Change action names. (e.g: migrate_live(v3) -> os-migrateLive(v2))
* Change v3 API attribute names to v2 ones.
* Change the API parsers of v3 code.
* Change the API schemas of input validation.
* Change v3 API behaviors to v2 ones.
On some APIs, there are different behaviors.
For example, v3 "create a private flavor" API adds a flavor access for its
own project automatically, but v2 one doesn't.
The following work item is not mandatory and it is one of wishlist.
* Change v3 plugin code path.
e.g::
nova/api/openstack/compute/plugins/v3/servers.py
-> nova/api/openstack/compute/plugins/servers.py
Dependencies
============
None
Testing
=======
Tempest has already contained a lot of v2 API tests, and that is a good test
coverage now. For this v2.1 API, we need to run v2 API tests for both current
v2 and v2.1 in parallel. As an idea, we will add v2.1 API tests by inheriting
from the existing v2 API test classes and executing them against /v2.1.
A spec for this idea has been already proposed:
https://review.openstack.org/#/c/96661/
Documentation Impact
====================
The documentation for the v2 API will essentially remain the same as the API
will not change except for improvements in input validation. There will need
to be some updates on possible error status codes.
Longer term the improved infrastructure for input validation and the
development of JSON schema for response validation will make it much
easier to automate the generation of documentation for v2 rather relying
on the current mostly manual process.
References
==========
* Juno Mid-Cycle meetup https://etherpad.openstack.org/p/juno-nova-mid-cycle-meetup
* Juno design summit discussion https://etherpad.openstack.org/p/juno-nova-v2-on-v3-api-poc
* Mailing list discussions about the Nova V3 API and the maintenance
overhead
* http://lists.openstack.org/pipermail/openstack-dev/2014-March/028724.html
* http://lists.openstack.org/pipermail/openstack-dev/2014-February/027896.html
* Etherpad page which discusses the V2 on V3 Proof of Concept and
keeps track of the ongoing work.
* https://etherpad.openstack.org/p/NovaV2OnV3POC
* Document about the problems with the V2 API
* http://ozlabs.org/~cyeoh/V3_API.html
* Document describing the current differences between the V2 and V3 API
* https://wiki.openstack.org/wiki/NovaAPIv2tov3

198
specs/kilo/implemented/vmware-driver-ova-support.rst Normal file
View File

@@ -0,0 +1,198 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
==================
VMware OVA support
==================
https://blueprints.launchpad.net/nova/+spec/vmware-driver-ova-support
This blueprint proposes to add support of spawning an instance from the disk
embedded in an OVA (`Open Virtualization Application <http://www.dmtf.org/standards/ovf>`_) glance image.
Problem description
===================
Given that the best practice for obtaining a compact, portable template of a
virtual machine in the vSphere platform is to export it into an OVF folder or
an OVA file, a frequent customer ask is to
be able to deploy them in OpenStack as Glance images and spawn new instances
with them.
In addition, OVF/OVA contains virtual disks that are converted to the
streamOptimized format, and streamOptimized disks are the only disk type
deployable on vSAN datastores (see blueprint `vmware-vsan-support <https://blueprints.launchpad.net/nova/+spec/vmware-vsan-support>`_)
Since exporting a virtual machine to OVA/OVF remains one of the most convenient
means to obtain streamOptimized disks, providing support for spawning using OVA
glance images will streamline the process of providing images for vSAN use.
Use Cases
----------
The end user will be able to export a VM from vCenter or any system
supporting the Open Virtualization Format and import it to OpenStack
without any transformation.
Project Priority
-----------------
None
Proposed change
===============
An OVF contains additional information about the virtual machine beyond its
disks - it has an .ovf XML descriptor file that describes the virtual machine
configuration (memory, CPU settings, virtual devices, etc). But for the
purpose of this blueprint, it is treated essential as a container of a root
disk targetted for the spawn process.
Note: An OVA is essentially a tarball of an OVF bundle. Given the current
image-as-a-single-file nature of glance images, it is more straightforward to
support the uploading/download of OVA as a Glance image.
The blueprint propose to support spawning of an image of container format 'ova'
and disk format 'vmdk'. The driver expects the image to be an OVA tar bundle.
While much of the information in the XML descriptor file could prove useful in
the proper configuration of the spawned virtual machine in the future, the
implementation of this blueprint will only perform minimal processing of the
XML file solely for the purpose of obtaining the right disk file to use for
spawn as well as type of the virtual disk adapter that the disk should be
attached to by default. The disk adapter type used will continue to be
overridable by specifying the "vmware_adaptertype" property in the spawn
operation.
Alternatives
------------
* When implemented, the vmware-vsan-support blueprint will allow spawning of
streamOptimized disk. An alternative is to force all users to extract the
streamOptimized disk from any OVA/OVF they intend to deploy in OpenStack and
have the compute driver only support spawning of a streamOptimized disk
image. This that puts unnecesary burden on the user.
* Use the Task framework under proposal in Glance to provide on-the-fly
conversion of a supplied OVF/OVA into some other appropriate forms. This is
closely related to the previous alternative, as it may provide a more
streamlined workflow in glance to degenerate an incoming OVF into a single
streamOptimized disk.
* Add support for OVF folder as the portable vSphere VM image. Since an OVF is
a folder with multiple files, it does not work well with existing the glance
model.
* There are other proposals that involves using images that references data in
the hypervisor's datastore, or storing images directly on the datastore.
These are welcome optimizations that will reduce the amount of glance<->nova
nova transfers, but they do not address the issue of providing portable
image data that can be deployed in other vCenter installations.
* Continue to force customers to upload images using the flat and sparse disk
variants. Because there is no straightforward way of obtaining disk images of
these type while still adopting the best practice of exporting virtual
machines first, this leads a separate, lengthier and more error-prone
workflow for preparing images for OpenStack use.
* Add logic in the client code to extract the content of the OVA and upload the
VMDK content rather than than the entire OVA.
Data model impact
-----------------
None.
REST API impact
---------------
None.
Security impact
---------------
None.
Notifications impact
--------------------
None.
Other end user impact
---------------------
Users will be able to use the OVA images that they have been uploading
to Glance without being able to use them.
Performance Impact
------------------
OVA and streamOptimized disks are more space efficient and streamable, this
means less storage use in glance and faster first-time deployment times (as
compared to a flat or sparse disk image).
Other deployer impact
---------------------
This change will allow deployment of existing libraries of exported OVA images,
with little or no additional transformations. Existing image using flat/sparse
disk types may be deprecated/deleted in favor of OVA (or standalone
streamOptimized disks).
Developer impact
----------------
None.
Implementation
==============
Assignee(s)
-----------
Primary assignee:
arnaudleg
Other contributors:
tflower
Work Items
----------
* Download OVA, process embedded .ovf descriptor file for the path to the
root disk in the OVA, and spawn using data from said disk.
Dependencies
============
None.
Testing
=======
Since Tempest in general does not support driver-specific tests, the proposal
is to update the `VMware NSX CI <https://wiki.openstack.org/wiki/NovaVMware/Minesweeper>`_
with additional tests
to verify spawning of instances using OVA images uploaded to glance with the
'ova' container format.
Documentation Impact
====================
In addition, new information in the vmware driver section of the Nova
documentation will have to be added to document:
* The parameters to use when uploading an OVA image.
* The scope of the information contained in the OVA that is used in the spawn
process (essentially information pertaining to obtaining the root disk and
not much else)
References
==========
* http://www.dmtf.org/standards/ovf
* https://wiki.openstack.org/wiki/NovaVMware/Minesweeper
* https://bugs.launchpad.net/glance/+bug/1286375

191
specs/kilo/implemented/vmware-vsan-support.rst Normal file
View File

@@ -0,0 +1,191 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
===================================
VMware: Support for vSAN Datastores
===================================
https://blueprints.launchpad.net/nova/+spec/vmware-vsan-support
Currently the vmwareapi compute driver only supports deploying instances to NFS
and VMFS datastores. This blueprint proposes to add support for using vSAN
storage as well.
Explanation of terminology used:
The term "datastore" as referred to in the spec and the driver refers to
the vSphere concept a logical storage container, a place where VM data (among
other things) is kept. The purpose of this abstraction is to provide a uniform
way for vSphere clients to access said VM data regardless of what hardware, I/O
protocols or transport protocols are used by the underlying storage.
All vSphere datastores until recently has been broadly divided into two types,
VMFS and NFS. The vmwareapi driver has been supporting the use of both since
its inception, without having to distinguish between either, largely because of
this datastore abstraction.
vSAN storage is a third type of datastore introduced in vSphere. It is
a software-defined distributed storage that aggregates disks (magnetic for
capacity, SSD for cache/performance) attached to a group of hosts into a
single storage pool. That pool is once again exposed as a single datastore.
Problem description
===================
Currently datastores with type "vsan" is ignored by compute driver entirely.
One obstacle to using this type of datastore is that virtual disk data files
(the "-flat.vmdk" files) are not directly addressable as datastore paths. Since
both the spawn and snapshot workflow in the vmware driver addresses the data
files in some way, they will have to be changed to support vSAN datastores.
Use Cases
----------
The End User will be able to use vSAN datastores and deploy streamOptimized
images.
Project Priority
-----------------
None
Proposed change
===============
The change is divided into two areas:
* Recognize and use datastores of a new type ("vsan").
* Update existing code involved in exporting and importing Glance images to
use alternate vSphere APIs that does not address disk data files directly.
The second area of change is mainly provided by the image-transfer
functionality in the oslo.vmware library [*]_. The proposal is to update the
code to use said library.
However, the only disk format that these alternate APIs support is the
'streamOptimized' format. (The streamOptimized format is a sparse, compressed,
and stream-friendly version of the VMDK disk that is well suited for
import/export use cases, such as the glance<->hypervisor exchanges described
above). This implies that only streamOptimized disk images are deployable on
vSAN. The driver will be modified to recognize Glance vmdk images tagged
with the property vmware_disktype='streamOptimized' as disks of such format,
and only use the alternate APIs when handling disks of this format.
.. [*] To import a disk image to a vSAN datastore, oslo.vmware uses the
ImportVApp vSphere API is used to import the image as a shadow virtual
machine (a VM container to hold a reference to the base disk disk, and is
not meant to be powered on). Likewise, to export the disk image, the library
uses the ExportVM vSphere API. These APIs do not reference the virtual disk
data file paths directly and are hence compatible with vSAN storage.
Alternatives
------------
None.
Data model impact
-----------------
None
REST API impact
---------------
None
Security impact
---------------
None
Notifications impact
--------------------
None
Other end user impact
---------------------
None
Performance Impact
------------------
None
Other deployer impact
---------------------
There is a new configuration option under the [vmware] section,
"image_transfer_timeout_secs", which configures how long an image transfer can
proceed before timing out.
In order to deploy existing VMDK images to vSAN, these images will have to be
converted to streamOptimized and reimported to glance.
Developer impact
----------------
Minimal. The changes related to blueprint are mostly isolated in the areas of
handling a new vmdk format type and add recognition and use of an additional
datastore type called "vsan".
Implementation
==============
Assignee(s)
-----------
Primary assignee:
rgerganov
Work Items
----------
The work is broadly decomposed into:
* use oslo.vmware image_transfer module to handle download of images
* use oslo.vmware image_transfer module to handle upload of image snapshot
* update driver to allow the use of datastores of type vSAN.
* update driver to recognized a new vmdk format (streamOptimized)
Dependencies
============
None
Testing
=======
Since Tempest in general does not support driver-specific tests, the proposal
is to update the MineSweeper CI
(https://wiki.openstack.org/wiki/NovaVMware/Minesweeper), to provide
vCenter with vSAN storage and additional tests to verify existing Tempest
tests passes when invoked against compute nodes using it.
Documentation Impact
====================
New information in the vmware driver section of the Nova documentation will
have to be added to document:
* How to configure a compute node for vSAN use.
* The virtual disk format requirement ("streamOptimized" only) when using vSAN
storage.
* The new "image_transfer_timeout_secs" configuration option.
* How to obtain a streamOptimized disk from a virtual machine or vmdk disk in a
non-streamOptimized format.
References
==========
* https://github.com/openstack/oslo.vmware
* https://wiki.openstack.org/wiki/NovaVMware/Minesweeper