Commit 1337890ace removed InstanceV1 objects.
We need to provide a note for that, even if that's only for CDs.
Change-Id: I4b349c2e02323a6aa04d45534055dccfc3e1be8f
Change 296479e1ab removed support of 'always' for
force_config_drive opt. We need to provide a reno file for that.
Change-Id: I1c7ad84196acb045406bbd974fe2e846d135b87d
Change Ifbd5578dcc53b2117674db2016e5d882a82866aa deprecated the local conductor
mode. We need to provide a reno note for that.
Change-Id: Ia9a65b5a414693efa2cf102ace88e41e2fd8ff87
Sphinx was giving a warning because of the bad string having `'.
Since we want to better linting the notes, we need to fix that.
Also adding an empty line between the 2 sections to be cleaner.
Change-Id: Ic6b1a4c71592bf41ee8148db147cf014ba2922f3
If an exception is raised out of the _report_state call, we find that
the service no longer reports any updates to the database, so the
service is considered dead, thus creating a kind of zombie service.
I55417a5b91282c69432bb2ab64441c5cea474d31 seems to introduce a
regression, which leads to nova-* services marked as 'down', if an
error happens in a remote nova-conductor while processing a state
report: only Timeout errors are currently handled, but other errors
are possible, e.g. a DBError (wrapped with RemoteError on RPC
client side), if a DB temporarily goes away. This unhandled exception
will effectively break the state reporting thread - service will be
up again only after restart.
While the intention of I55417a5b91282c69432bb2ab64441c5cea474d31 was
to avoid cathing all the possible exceptions, but it looks like we must
do that to avoid creating a zombie.
The other part of that change was to ensure that during upgrade, we do
not spam the log server about MessagingTimeouts while the
nova-conductors are being restarted. This change ensures that still
happens.
Closes-Bug: #1517926
Change-Id: I44f118f82fbb811b790222face4c74d79795fe21
* There isn't any support specify a host for cold migration API.
Remove the words about cold migration can do explicitly decision.
* Use some cloud operators instead of some users for resource
optimization case.
blueprint complete-todo-in-api-concept-doc
Change-Id: Iea266d61551666edfa4f6bb3d4f3d3f03c8b57f4
The api guide server concepts section uses the terms
instance and server interchangably and inconsistently.
This patch fixes that.
blueprint complete-todo-in-api-concept-doc
Change-Id: Iafa57c90c010f4bfba493b917ee4f82986739769
I have moved the resize and shelved operations after the discussion of
the cloud operator initiated migrate. This adds better context around
the comments that say resize and shelved are unlikely to be initiated by
and operator.
blueprint complete-todo-in-api-concept-doc
Change-Id: I7fd72b5fd2d4e724d4465fe002f7951e60dcbe3d
This adds in some titles, to replace the bold text that simulated
heading. It also changes the text into use cases rather than actions.
It includes a some additions around:
* resource optimization use cases for live-migration
* data loss during evacuate
* downtime during resize
* clearer description of why a user would call shelve
This does not complete this doc, but should help improve the readability.
blueprint complete-todo-in-api-concept-doc
Change-Id: Ib2cf479c14a1c2f3b119ba7f549a00c9bd541cf9
As of o.vo 0.4.0, FlexibleBooleanField has existed in o.vo, so change
Nova over to use o.vo's version of it.
Change-Id: If016161ea213f2226499eda792265a7a092f1385
Migration (including cold and live migration), resize and shelve
are three concepts at the API level that support three distinct
sets of use cases. These all involve movement of servers and
so provide opportunity for operational efficiency.
This patch adds a section to the server concepts that outlines
the purpose behind the actions and the operational efficiencies
that can be gained by them.
blueprint complete-todo-in-api-concept-doc
Change-Id: I6b9c6c179c1bdd9400abae7deb1918b370ddaefd
There's already a helper method for unshelve_instance. It turns out
that the other two places in this file which call select_destinations
can use the same helper. Doing this removes some code redundancy.
I haven't pushed build_request_spec in as well because for bp
check-destination-on-migrations we won't always be constructing a
brand new request spec.
Change-Id: I19bad96d997f61958e32f6254bc4a428395bc7ec
Sylvain Bauza