openstack/nova-specs - nova-specs - OpenDev: Free Software Needs Free Tools

This was a feature from Nova legacy API codebase that had 0 testing,
and only hints of documentation. This proposes to bring it back in a
very limited (and deprecated way) for the current code.
Change-Id: I70a8c8e76f234611f4b2972b3adae86ca09da012

When an instance is rescued the libvirt driver creates a file in the.
instance directory that contains the original instance xml. This file
is used when unrescuing the instance to revert to the original disk
configuration. However, this file is not necessary to restore the
instance's original configuration. Furthermore the reliance on this
file means we currently cannot live migrate a rescued instance. Thus
it is proposed that we do not create this file during the rescue
operation and rebuild the instance's original xml file from the
database when we unrescue it.
APIImpact
Change-Id: Id3a055f00c3f8ef006911e2523c8d284f449b524

Spec to automate the use of various libvirt/qemu
features to complete live migrations when instance
memory access rate is high.
Change-Id: Id0b334ba8c4d97b3eaa58a6fe3b1242560567853
Blueprint: auto-live-migration-completion

Propose a way with XenServer compute driver to support neutron
security group when ML2 OVS is used
Change-Id: Ie1d671c5a31402d8c71092e37d4b03e1e517d67a
Blueprint: support-neutron-security-group

bp remove-compute-compute-communication
Change-Id: I783c5b4e39c5252d0e29592f0c229e0f38446b66

Currently, os-migrations API does not support pagination
and timestamp filtering. As for large scale production
deployment, the number of migration records can be very
big, it will be very useful to add pagination and time
stamp filtering support for os-migrations API.
APIImpact
DocImpact
Change-Id: Iab602f13dbacd481a690b5f041da8bb4ba044afc
Implements: blueprint add-pagination-and-change-since-for-migration-list

Currently, os-instance-actions API does not support pagination.
As in production deployment the number of instance action records
can be also very large query them all can lead to performance
bottleneck, it will be very useful to support pagination.
Also, os-instance-actions API does not support filter the migration
record by last updated time. As for production deployment, an instance
can be up for a very long time, and the number of migration records
will also be very big. It will be very useful to support filter by
last update time.
APIImpact
DocImpact
Change-Id: I9ac4d73c120292fbe9e075d5da2549bdf6a6feaf
Implements: blueprint pagination-add-changes-since-for-instance-action-list

APIImpact
bp: async-live-migration-rest-check
Change-Id: I07d0581cc7db9b5fdc34073625a548d1f42f8633

This update adds consideration for cells v2 to the
convert consoles to objects spec. It also explicitly
refers to deprecation of the consoleauth service instead
of just memcachd.
Change-Id: Icf6a328c9b391f1e28f51b935b1785c9c454f33f

The ability to run Nova compute services independently from the
XenServer host which is running the virtual machines would enable more
flexible deployment and development models, and would significantly
lower the barrier to entry for XenAPI developers.
This spec makes the necessary changes to enable this independent mode
of deployment, where the Nova compute services could be running on an
entirely different machine
Change-Id: Ibb793ca029173de5c720e10eb3d016d7ffbaf264

Neutron added the ``auto-allocate-topology`` API in Mitaka [1]_. Nova intends
on using this API to automatically allocate a private network for a project
when creating server instance if no specific network is provided in the create
request and none are available to the project. This should also bring some
feature parity for the server create flow between Neutron and nova-network.
Spec for blueprint get-me-a-network
APIImpact
Change-Id: If34d760deb5fc1c580b4c84d0a569b532bd1385f

This feature adds the possibility to define a flavor,
that does not create any ephemeral disks locally on the hypervisor.
If the new flavor key 'local_disks' is set to 'False', users are
"forced" to create a bootable volume to launch an instance from
that flavor.
APIImpact
DocImpact
Change-Id: I52b8d473d86ce471e61a2c3505f6c274ad0643b8
Implements: blueprint flavor-root-disk-none

Change-Id: I138fedf8da915a7e8b2ec5662c8f34e555b223cb
Previously-approved: mitaka

Proposal to support pagination for hypervisor.
APIImapct
Change-Id: I72b18b38cad98a415eced49fababfcc280d39f3b
Blueprint: pagination-for-hypervisor

This describes how we should deprecate API proxies to make them less
used in the wild.
APIImpact
Change-Id: Icca01fc8b2f24340a53feaf212a022e89096319a

Glance v1 is subject to deprecation, we need Nova to move away
from v1 and use v2 fully. This spec discusses how we plan to
make that transition. This also documents the testing plan
for both v1 and v2 and few limitations associated with it.
Previously-approved: Mitaka
Change-Id: I1247b436f9cbb21eb6e3d5cbabe5345e6037ceb2
Co-authored-by: Flavio Percoco <flaper87@gmail.com>
Co-authored-by: Sudipta Biswas <sbiswas7@in.ibm.com>

blueprint cells-instance-groups-api-db
Change-Id: Ie5f9cbbf28c3b105ea7d02bc5d6ab97a1db9c04d

Blueprint adds pagination support for key pairs.
Optional parameters 'limit' and 'marker' will be added
to GET /os-keypairs request and 'key_pair_get_all_by_user'
DP API function will be updated to order_by key pairs by user_id.
Co-Authored-By: Sergey Nikitin <snikitin@mirantis.com>
APIImpact
Blueprint: keypairs-pagination
Change-Id: Ie9e4230494d5ba95d2e94ef47de15c8f7d7fd8fe

In mitaka-template.rst file, there is a link which forwards to
a slightly deprecated site about blueprints and specs.
In the current template [1] under
"Some notes about the nova-spec and blueprint process:"
there are several points, the first one is:
 * Not all blueprints need a spec. For more information see
 http://docs.openstack.org/developer/nova/devref/kilo.blueprints.html#when-is-a-blueprint-needed
This link refers to documentation of Kilo release, and
there is information about Juno and Kilo release, which may be misleading.
This link is being replaced with [2] which is
the current version of the blueprint document.
[1] https://github.com/openstack/nova-specs/blob/master/specs/mitaka-template.rst
[2] http://docs.openstack.org/developer/nova/blueprints.html
Change-Id: I2a178966b65f628d5752c5327aeda8b625f190ba
Closes-Bug: #1582783 

Add a spec for the work to split allocate_for_instance into to parts,
such that we will be able to do network aware scheduling in the near
future for neutron's routed networks spec.
blueprint prep-for-network-aware-scheduling
Change-Id: I1a71e83d9fb3d13306979934fbd11faf80091ab8

In Mitaka the basic infrastructure for the versioned notification has been
merged. Now it is time to start transforming our existing legacy
notifications to the new format. This spec proposes the first couple of
transformations.
Implements: blueprint versioned-notification-transformation-newton
Change-Id: I71a57678245b8da1cfca48c944fab06a03f58da9

As discussed at the Newton summit, we don't love having pluggable
modules for vendordata, but we would be willing to have an
external REST service which provides metadata. This spec explores
what an implementation of that could look like.
Blueprint: vendordata-reboot
Change-Id: Ibd5714be954838dbf8636e6988cb91d50f5c3baf