Per comments in I6815958b2533d462a2e5d27e7be57440d9f4f40a and
I5fdafd9f6cf07a19bf86a6343663dad410887dcb.
Part of bp: doc-migration
Change-Id: Iac833503b57386ab91fa86f8c48f0dd8039e5922
There are some small comments on the review of
Ib2b49f70c55311195535a5ef250ff555e227fa0a
This is a follow-up for these comments.
Change-Id: I1d2d95a0864578161a34084db31eb460e895c1ec
FilterScheduler is the only scheduler driver that properly integrated
with placement api so this patch changes the functional test environment
to use the FilterScheduler instead of the ChanceScheduler.
The amount of vcpu the SmallFakeDriver reports need to be bumped to 2
as during resize to same host the filter scheduler doubles the
allocation on the host. Simply relying on the 16.0 default allocation
ratio does not work as the max_unit of the vcpu does not use the
allocation ratio to avoid that a single server overallocates the cpu.
The only change in unit test is
test_create_instance_with_oversubscribed_cpu which also loads the
SmallFakeDriver and asserts available resources on it.
Change-Id: I12de2e195022593ea2a3e2894f2c3b5226930d4f
api.rst has many stale information now as we have done
many changes in api framework specially removal of
stevedore extensions loading and plain routing.
This commit modify this doc to reflect latest information
and remove v2 specific info which are no longer valid.
Note- in next part we will merge api_2.rst in this doc and
show 'adding api method' step by step.
Change-Id: I0628d8fa0b19c3fb09f1896402fc85dcae90916f
Detail these features, including links to the documentation. No tests
are provided as no upstream Tempest tests currently exist.
Change-Id: I1bb3674f35f83e2a33243103a267b4aff70f852e
When attaching a volume, if CONF.cinder.cross_az_attach=False,
we attempt to lookup the AZ that the instance is in and compare
that to the volume AZ. The instance AZ lookup involves getting
host aggregates which are in the API database, and in superconductor
mode the cell conductor can't access to the API database.
For volume attach, we could remove this check from the compute
service since we already check this in nova-api so the check in
nova-compute is redundant.
However, we still have a problem with checking this during boot
from volume where nova-compute creates the volume and then
attaches it. At that point it's too late and we'll fail.
We should eventually create volumes during boot from volume in
conductor, like we've talked about doing with neutron ports
during server create, but that's not something we have today
so we need to point out this limitation.
Change-Id: I9cbe41e41f8ccdc9962ab593f313b5a47314a9d1
There is an up-call from the xenapi driver when performing a live
migration and --block-migrate is not specified such that the driver
checks to see if the source and destination hosts are in the same
aggregate. This fails in a super-conductor setup because the
aggregates are now in the API database and the cell conductor
won't be able to access that database by design.
Change-Id: I6c880c72d87eb0116cb57371e5d600dced2915f7
Related-Bug: #1709594
This addresses review comments made in change
I6522100a78241400b1ea059a39a32c259fe6ab90 which
updated the stable API docs.
Change-Id: Ib0ffe3e9702fd39914b2025096667e699bc432a0
Because we need to allow for a smooth upgrade from Ocata to
Pike, we need Pike compute hosts to be tolerant of the bad accounting
assumptions that Ocata compute hosts were making. If a user migrates an
instance from an Ocata compute host to a Pike compute host, the Ocata
compute host will continue essentially re-setting the instance
allocation to be an allocation against only the source Ocata host
(during the migration operation). We need to have the Pike destination
compute host recognize when its in a mixed Ocata/Pike environment and
tolerate this incorrect "healing" that the Ocata source host will do.
To tolerate this, the Pike destination compute host must continue to
behave like an Ocata compute host until all compute hosts are upgraded
to Pike or beyond.
Note that this adds service version caching for the compute service.
We were already doing the lookup for the RPC pin and caching that,
so this is not much of a change. Also note that we weren't clearing
this caching in tests, so any test that ran code that cached the
service version would affect later ones. This clears it as part of the
base test setup too.
Co-Authored-By: Jay Pipes <jaypipes@gmail.com>
Change-Id: Ia93168b1560267178059284186fb2b7096c7e81f
The ec2 / euca2ools command references definitely don't work any more,
this deletes most of them. The exception is the policy reference doc
which is over a year out of date, and needs more then surgical removal
of ec2 from it.
Change-Id: I963170f99037d5ed085e8c676ab55750c7f6372e
Missing from our contributor guides is documentation guidelines,
starting a page there for now especially as there are a couple of
things that emerged in the great pike import that would be good to
write down.
Part of bp: doc-migration
Change-Id: Ib2b49f70c55311195535a5ef250ff555e227fa0a
The cli page was just a straight list of cli links. This groups them
by function with a preamble to make it more clear why you'd want to go
look at any particular ones.
Part of bp: doc-migration
Change-Id: Iecf99e173be3c3d5a2d5dd758c09f79d443729b9
Import the following files from the former config-reference [1]:
api.rst
cells.rst
fibre-channel.rst
hypervisor-basics.rst
hypervisor-hyper-v.rst
hypervisor-kvm.rst
hypervisor-lxc.rst
hypervisor-qemu.rst
hypervisor-virtuozzo.rst
hypervisor-vmware.rst
hypervisor-xen-api.rst
hypervisor-xen-libvirt.rst
hypervisors.rst
index.rst
iscsi-offload.rst
logs.rst
resize.rst
samples/api-paste.ini.rst
samples/index.rst
samples/policy.yaml.rst
samples/rootwrap.conf.rst
schedulers.rst
The below files are skipped as they're already included, in slightly
different forms, in the nova documentation.
config-options.rst
nova-conf-samples.rst
nova-conf.rst
nova.conf
Part of bp: doc-migration
Change-Id: I145e38149bf20a5e068f8cfe913f90c7ebeaad36
extensions, stevedore and extensions config options are gone
and plain router is introduced in Pike.
Also this documents was little bit confusing about current and
old state of APIs.
This commit makes it more clear and reflect the current API state
and also describe the evolution of APIs.
Change-Id: I6522100a78241400b1ea059a39a32c259fe6ab90
Most of these are used by the follow on patch, however because all
this content is deleted from openstack-manuals pulling these out of
history there is less straight forward. So bulk import even the ones
that aren't currently used into a top level figures repository.
Part of bp: doc-migration
Change-Id: I57929f3035f0a9f41398b50d93afee267d981f12
The index previously was written for the developer docs, but this is
more than developer docs now. That also means this is the general
google landing page for people, so a basic "what is nova" is
appropriate.
Part of bp: doc-migration
Change-Id: I5fdafd9f6cf07a19bf86a6343663dad410887dcb
This provides a more detailed, but still high level, explanation
of how the FilterScheduler is using allocation candidates to pick
hosts during scheduling, and how the allocations are handled during
a move operation, including a resize to the same host.
Ideally this content will live somewhere else in the devref, or
would be updated in the spec for blueprint placement-claims, but
for now this should suffice for Pike release notes that can point
at this upgrade doc.
Change-Id: I274c684f829bc310ebb17faabf498d36f4ceea0c
This adds information about where the consoleauth service and console
proxies should run with multiple cells in Cells v2.
Change-Id: Ib817581dfe0c32d3888c242166e3daa7b954320a
This attempts to reorganize the front page content relevant to
operators into digestable chunks, including some summaries of links to
explain to people why they might want to follow those links to learn
more.
Part of bp: doc-migration
Change-Id: I6815958b2533d462a2e5d27e7be57440d9f4f40a
This reorganizes the pieces that are for end users into a convenient
chunk up front in the main index page.
Part of bp: doc-migration
Change-Id: Ic2fcabbf3faa531fccb19cffa2564f005142e463
Online data migrations that move something from the cell database
to the API database typically create new things in the API DB and
on a query, look in the API DB first and then fallback to the cell
database. We started supporting multiple cells in Pike, so any online
data migrations that move things to the API DB after that will need
to be multi-cell aware for the fallback lookup code.
This just adds a reminder in the code review guide.
Change-Id: If0d7d9b80e336b696aaf87ec13ac18daa1068357
Jenkins