This is primarily a writing style cleanup with some clarifications
and link additions. It does not make any great effort to bring the
information up to date with current conditions.
Change-Id: I665dc5afc952cf93c095cdd1421b64d7b0716b2a
As extensions are already deprecated in Nova, this patch removes
all of the details about extensions, adds a note about the deprecation
of extensions, and points to documentation about microversions for
discovering API changes.
blueprint complete-todo-in-api-concept-doc
Co-Author: Ed Leafe <ed@leafe.com>
Change-Id: I56acfeac5b8b3312547c06d79962a79991c5c8f3
Add description for server trigger crash dump operation
into api-guide.
Change-Id: I20492dbf9eab4f7fcab0864bb250b20f98b762e4
blueprint complete-todo-in-api-concept-doc
It is very helpful when we bump service rpc version since we have
test_version() case to cover that, but sometime we do rebase/bump
rpc service version we may forget to increae compute_manager's version,
in this case test_version give a wrong message will make `new` developer
confused, and spend time to do debuging, this patch improves the error
message.
Change-Id: I64320b5a46aa0543e3d9e8fdd27f6faa3829cf69
The default fixed_ip allocation always does .first() out of the fixed
ip pool. This leads to a pathological situation that in a rapidly
changing environment we're constantly recycling the same small number
of ips out of the pool. Given other racey behavior in dnsmasq around
processing DHCP Release requests, we can start to get DHCP fails when
a DHCP release is missed, we immediately recycle the IP and give it to
a new guest.
We can mitigate this by sorting the results by updated_at. This
means we'll favor least recently used fixed ips.
Depends-On: I27f73c1edf12218818c4d279efbd9fef5cdef672
Related-Bug: #1532809
Change-Id: I3c83bd68a0e2bbbcdd6d955722dbc9f9fc528113
This reverts commit 4b142e53e43132e996d35c335da30959f9f361be.
I was having a point left unresolved in https://review.openstack.org/#/c/189279/8/doc/source/filter_scheduler.rst about the tech debt that adding a new filter in-tree would cause for something very closely related to another filter.
I totally get the need for adding more logic and reverting how we compare flavors vs. aggregates. I just feel that before committing ourselves to that, we need to correctly estimate the possibilities to modify AggregateInstanceExtraSpecsFilter to fit the above needs.
Change-Id: Ic9f70dae037d32980a5a252bdd08eff02ba27120
Provider firewall rules functionality is not in use and hasn't been
for a very long time. The api for this was removed in [1] and db api
methods for adding/removing rows in the associated db table have not
been used since.
Stop refreshing those rules as it is essentially a no-op and indeed a
costly one that includes a rpc round trip to the conductor to get
back an always empty db result. This should have a positive impact on
instance boot performance since the conductor call happens to live
inside an externally syncronized block of code.
Removes related compute rpcapi/manager code that were missed in a
recent cleanup[2]. Since this functionality hasn't been in use since
Havana timeframe(!), it should be fairly safe to remove without first
deprecating it.
Also removes the now unused virtapi method provider_fw_rule_get_all()
and the virtapi itself from virt firewall driver initialization.
[1] Commit: 62d5fae8d1
[2] Commit: e6f7d80417
Change-Id: Ifbb2514b9bc1445eaa07dcfe172c7405fd1a58f7
Partial-Bug: #1016633
Chris Dent