Move config options of nova.conf section "upgrade_levels" to new
centralized location nova/conf/upgrade_levels.
Also, previously some config options for "upgrade_levels" were scattered
in different conf files. Moved these options to the central
location: nova/conf/upgrade_levels.
Change-Id: I45651e8527dd98635f25e9586f68c288203d8cf5
Implements: blueprint centralize-config-options-newton
The oslo team is recommending everyone to switch to the
non-namespaced versions of libraries. Updating the hacking
rule to include a check to prevent oslo.* import from
creeping back in.
This commit includes:
- using oslo_utils instead of oslo.utils
- using oslo_serialization instead of oslo.serialization
- using oslo_db instead of oslo.db
- using oslo_i18n instead of oslo.i18n
- using oslo_middleware instead of oslo.middleware
- using oslo_config instead of oslo.config
- using oslo_messaging instead of "from oslo import messaging"
- using oslo_vmware instead of oslo.vmware
Change-Id: I3e2eb147b321ce3e928817b62abcb7d023c5f13f
Very simple import change in each file, just touches a
whole lot of files. jsonutils has graduated into a stand alone
library and has been removed from the oslo-incubator repository.
We should be using the library for all projects.
Change-Id: I09d780a47d377871f357654603ee4b0fa0169d66
The oslo.messaging library takes the existing RPC code from oslo and
wraps it in a sane API with well defined semantics around which we can
make a commitment to retain compatibility in future.
The patch is large, but the changes can be summarized as:
* oslo.messaging>=1.3.0a4 is required; a proper 1.3.0 release will be
pushed before the icehouse release candidates.
* The new rpc module has init() and cleanup() methods which manage the
global oslo.messaging transport state. The TRANSPORT and NOTIFIER
globals are conceptually similar to the current RPCIMPL global,
except we're free to create and use alternate Transport objects
in e.g. the cells code.
* The rpc.get_{client,server,notifier}() methods are just helpers
which wrap the global messaging state, specifiy serializers and
specify the use of the eventlet executor.
* In oslo.messaging, a request context is expected to be a dict so
we add a RequestContextSerializer which can serialize to and from
dicts using RequestContext.{to,from}_dict()
* The allowed_rpc_exception_modules configuration option is replaced
by an allowed_remote_exmods get_transport() parameter. This is not
something that users ever need to configure, but it is something
each project using oslo.messaging needs to be able to customize.
* The nova.rpcclient module is removed; it was only a helper class
to allow us split a lot of the more tedious changes out of this
patch.
* Finalizing the port from RpcProxy to RPCClient is straightforward.
We put the default topic, version and namespace into a Target and
contstruct the client using that.
* Porting endpoint classes (like ComputeManager) just involves setting
a target attribute on the class.
* The @client_exceptions() decorator has been renamed to
@expected_exceptions since it's used on the server side to designate
exceptions we expect the decorated method to raise.
* We maintain a global NOTIFIER object and create specializations of
it with specific publisher IDs in order to avoid notification driver
loading overhead.
* rpc.py contains transport aliases for backwards compatibility
purposes. setup.cfg also contains notification driver aliases for
backwards compat.
* The messaging options are moved about in nova.conf.sample because
the options are advertised via a oslo.config.opts entry point and
picked up by the generator.
* We use messaging.ConfFixture in tests to override oslo.messaging
config options, rather than making assumptions about the options
registered by the library.
The porting of cells code is particularly tricky:
* messaging.TransportURL parse() and str() replaces the
[un]parse_transport_url() methods. Note the complication that an
oslo.messaging transport URL can actually have multiple hosts in
order to support message broker clustering. Also the complication
of transport aliases in rpc.get_transport_url().
* proxy_rpc_to_manager() is fairly nasty. Right now, we're proxying
the on-the-wire message format over this call, but you can't supply
such messages to oslo.messaging's cast()/call() methods. Rather than
change the inter-cell RPC API to suit oslo.messaging, we instead
just unpack the topic, server, method and args from the message on
the remote side.
cells_api.RPCClientCellsProxy is a mock RPCClient implementation
which allows us to wrap up a RPC in the message format currently
used for inter-cell RPCs.
* Similarly, proxy_rpc_to_manager uses the on-the-wire format for
exception serialization, but this format is an implementation detail
of oslo.messaging's transport drivers. So, we need to duplicate the
exception serialization code in cells.messaging. We may find a way
to reconcile this in future - for example a ExceptionSerializer
class might work, but with the current format it might be difficult
for the deserializer to generically detect a serialized exception.
* CellsRPCDriver.start_servers() and InterCellRPCAPI._get_client()
need close review, but they're pretty straightforward ports of code
to listen on some specialized topics and connect to a remote cell
using its transport URL.
blueprint: oslo-messaging
Change-Id: Ib613e6300f2c215be90f924afbd223a3da053a69
Add a temporary nova.rpcclient.RPCClient helper class which translates
oslo.messaging.rpc.RPCClient compatible calls into calls on a RpcProxy
object.
Use this new class to port all of the rpcapi modules over to the new
RPCClient so that the final port of Nova over to oslo.messaging will be
smaller and easier to review.
This patch contains no functional changes at all, except that all client
side RPCs go through this temporary helper class.
blueprint: oslo-messaging
Change-Id: Iee86c36bcc474a604993618b8a2255af8c3d2f48
This is a first pass at client side version control for rpc. It allows
you to configure a max version of messages that clients are allowed to
send. You can find one example of how clients need to adapt in the
conductor rpcapi. All other changes in rpc apis since the grizzly
release are not applicable to this.
Some future improvements to this could be reporting the versions
supported by running services and having that be discoverable via the
API. We could also consider allow setting these client side version
caps via the API. For now, recommended values for these config
options while attempting a rolling upgrade will just have to be documented.
The config options allow specifying specific rpc api version numbers if
desired, but an alias of 'grizzly' is also supported. So typically at
the start of a rolling upgrade you'd have:
[upgrade_levels]
compute=grizzly
conductor=grizzly
scheduler=grizzly
... etc ...
And as you update all instances of a service, you would remove that bit
from your configuration across the deployment using your config management
system of choice.
DocImpact
Implements blueprint rpc-version-control.
Change-Id: I2c0fd6dd7484c87823846d7c31d6525d93cd1b43
Each service implemented the get_backdoor_port method individually. This
patch moves the implementation of this method to the base rpc API
instead, and removes the now unnecessary code from each of the services.
The server side method was left on all of the managers for rpc backwards
copmatibility. They can be removed on the next major rpc version bump
of those APIs.
Part of blueprint base-rpc-api.
Change-Id: Ia8838fafd80eb86a1c2d66f5e97370042d8d8c53
This patch adds an rpc API that is exposed by all services. The methods
in this API exist in their own namespace and are versioned independently
of the main API for the service.
The first method for this API is a simple ping() method. This method
exists in the conductor rpc API already, and could be more generally
useful. Other methods will be added in later patches.
The base rpc API will be exposed from all services automatically unless
they override the create_rpc_dispatcher method in the base manager
class. All services need to pass a service_name into the base manager
constructor. Some services already did this, but now it's needed for
all of them.
Implements blueprint base-rpc-api.
Change-Id: I02ab1970578bc53ba26461b533d06d1055c2d88e
Sujitha