There are two changes here:
1. The serial_console config option group help text is
updated to point out that hyper-v also supports serial
console access. This is based on virt drivers that
implement the 'get_serial_console' method.
2. The hypervisor feature matrix is updated to point out
that the vmware driver does not support getting serial
console output. This is based on virt drivers that
implement the 'get_console_output' method.
Closes-Bug: #1632135
Change-Id: Ibf7f865e2b768e5ea3d7a7ec7cbf77bd8997c50f
Add a section in "core-review" to document how experimental pipeline would
be used by Nova developers in order to consume the resources at the
right time.
Change-Id: I5df377032c2fcec18cdf71af2568e028373bcced
Modify rolling upgrade steps from exisitng nova upgrades
documentation. Also, add pre-requisites required for the
zero downtime upgrade under newly created "Plan your upgrade"
section.
Change-Id: I4e884ac051614d25258734c35208b3abfe5fd3a4
Co-Authored-By: Sivasathurappan Radhakrishnan <siva.radhakrishnan@intel.com>
At the newton midcycle we talked about the proposed
memory bandwidth monitor plugin and decided that we
really just don't want nova in the business of metrics
gathering, and are moving to deprecate that functionality.
There are several specs open related to adding more
metrics monitors and/or exposing existing ones, so this
codifies the policy on nova as metrics gatherer.
Change-Id: Ie47e91776bc36a22fd48d3673c69c842509489a1
The out of tree support section of the nova dev policy
document was pretty old and basically said hooks and
extension points are buyer beware, but doesn't mention
anything about why we don't want them (interoperability)
and the efforts the last few releases to actively
deprecate and remove hooks/extension points/classloading.
This change adds some more wording to that effect to
the doc.
Change-Id: Iaa1cf3ef7ac6e8e1d75f94e17aaba1058474acca
This updates the docs to point at our flashy new(ish)
api-ref compute REST API docs instead of those gross
crusty old inaccurate ones.
Change-Id: Ib5e157f3ff7a215be4cbf7e8744b3507f3b4b106
The auto generated class documentation link was 404 in the notification
devref as that documenation is not generated automatically any more.
This patch modifies the notification devref to include the interesting
part of the class documentation inline.
Change-Id: I7cbea16fc9682fa3c00eac16a51c4ed8588ba45c
Move all scheduler options into their one of two groups. Many of the
options are simply renamed to remove their 'scheduler_' prefix, with
some exceptions:
* scheduler_default_filters -> enabled_filters
* scheduler_baremetal_default_filters -> baremetal_enabled_filters
* scheduler_driver_task_period -> periodic_task_interval
* scheduler_tracks_instance_changes -> track_instance_changes
Change-Id: I3f48e52815e80c99612bcd10cb53331a8c995fc3
Co-Authored-By: Stephen Finucane <sfinucan@redhat.com>
Implements: blueprint centralize-config-options-ocata
Libvirt has "domainSetUserPassword" callback and virtuozzo driver
has an implementation for it. So in this patch we allow to use this
functionality for virtuozzo hypervisor.
Change-Id: Ia398afadfd9fd9544c5d843338ab25c0930d9f74
Implements: blueprint virtuozzo-instance-admin-password
Right on now the Filter Scheduler page it is difficult to find where the
section is on configuring and writing your own. The page is very long.
So this adds some section headers. In addition a note is added to
clarify that when you write your own filter "all_filters" doesn't
include "write your own", both available and default settings need to be
changed.
Change-Id: I99878d3b4dc839ff87bc581e61c85e4ae2c66b2c
This patch updates link that the patch [1] added to general purpose
feature matrix
[1] https://review.openstack.org/#/c/344483/
Implements: blueprint feature-classification
Change-Id: I0f5abaf68adcbb49e013c2778cce692c6d8a7327
Copy edit the feature classification document
to improve language and structure.
blueprint feature-classification
Change-Id: I0ca1f8270439109c3b525b2a22ba3f035f0426f0
Added details for:
1. Server create and delete
2. Server snapshot
3. Server power operations
4. Server rebuild and resize
blueprint feature-classification
Change-Id: I2f10b797432ca441bb067e026c6c31419144c110
The description of "Inject guest networking config" in
support-matrix is misleading. Correct it.
In fact, If we config static ip,
guest os can not access metadata service to get ip config.
Closes-Bug: #1612913
Change-Id: I1892e5273a77516dd8e1525e6064fb95fa65e4d3
We recently came to the conclusion that the original idea how the
config options of Nova should be documented are too hard to maintain.
The discussion can be found on the ML starting with:
http://lists.openstack.org/pipermail/openstack-dev/2016-May/095538.html
This change reflects the outcome of the discussion.
Change-Id: I27b2cbb663f3c9a8c2503c3148280a3844f69cdd
As discussed at the newton midcycle and in the dev
mailing list:
http://lists.openstack.org/pipermail/openstack-dev/2016-July/099860.html
We should add a Tempest test for any microversion that
changes the response schema so we have coverage in Tempest
and also so we don't have to fill large gaps in coverage
in Tempest when adding other unrelated tests.
Change-Id: Ie7cfe7ee857caf630d4380cf673ae208842fbc00
The nova team would like to stop dynamically loading python modules to
implement vendordata in the metadata service and configdrive. Instead, we
propose to provide a module which can fetch dynamic vendordata from an
external REST server.
Things still to do:
- Documentation
- Support HTTP caching headers
- Cache vendordata responses
- Write vendordata documentation
- Unit test coverage of requests exceptions
- Unit test coverage of attempted vd overwrites
Blueprint: vendordata-reboot
Change-Id: I19c61a637a640a00f90c6bc8e82c38e7d4084493
Added details for:
1. Server volumes ops
2. Server block device mapping
3. Server neutron
4. Server pause
5. Server suspend
blueprint feature-classification
Change-Id: I6fe7ce561e47fc09939a7e4ddc25e19f07adef2d
Lets focus on server operations that must be tested for each of the Nova
virt drivers, such as create a server and snapshot a server.
This initial list is not meant to be complete, rather its some of the
key headline server actions that we should look at first. This list
includes all actions of the above type that are included in DefCore.
Follow changes will look at correctly populating the data for each of
the features that have been included.
blueprint feature-classification
Change-Id: Ibe31acbae38ea9f2b06aedded66aa486ed1f5cb8
Add in feature_classification.ini that makes use of new sphinx
extension feature_matrix. While it is loosely based on the
support_matrix extension, longer term this extension will live
outside the Nova tree. As such, this has been created as a new
separate sphinx plugin.
The matrix has links to wiki page for the CI in the header of the
summary matrix. This is called a target.
Also, there are links to admin docs, API docs, and tempest test uuids
added into the feature details. An option is added to ensure these are
always present in the prototype matrix.
A maturity status is added to be clear about the level of maturity
of each feature. When in maturity mode, this is added into the summary
table in place of the status. There is also some formating for the
different maturity levels.
blueprint feature-classification
Change-Id: Ib5895e8de901f1a282d0f5c0ecb811ff8b451497
Jenkins