[openstack-dev] Nova's service infrastructure in openstack-common
asalkeld at redhat.com
Mon Sep 10 22:31:51 UTC 2012
On 10/09/12 22:30 +0100, Mark McLoughlin wrote:
>Looking at the service infrastructure stuff proposed for
>I always get a bit lost with all the classes and abstractions we have
>going on this space, so I spent some time thinking about how it might be
>None of this is necessarily stuff that needs fixing before your patches
>can be merged, but I felt we needed to have a better picture of where
>So ... my attempt at simplifying the abstractions:
> - A Launcher class with the following methods:
> A launcher can be responsible for multiple services.
> There are two subclasses of this. The first - ServiceLauncher -
> handles a TERM/INT signal by stopping the services. The second -
> ProcessLauncher - will start a number of child processes, each child
> process running the service.
> - A Service class with the following methods:
> A service is associated with a Server object.
> A service also has a thread group whose members are stopped when the
> service is stopped.
> - A Server base class with the following methods:
> Server sub-classes PeriodicTasks, so it supports the @periodic_task
> decorator on its methods. The init() method of Server will spawn a
> timer thread from the service's thread group to run the periodic
> tasks from.
> There are two further sub-classes of Server which themselves are also
> base classes - rpc.Server and wsgi.Server. Sub-classes of rpc.Server
> and wsgi.Server will typically hook into the init() method and add
> methods which are decorated with @periodic_task.
> - The rpc.Server base class creates an RPC dispatcher which exposes all
> of the server's public methods over RPC via a given topic. All RPC
> calls will be handled in a thread spawned from the service's thread
> - The wsgi.Server base class exposes a WSGI over application a given
> port and spawns threads from the service's thread group to handle
>The differences between this and what we currently have is:
> - We no longer have these fairly similar "manager" and "server"
> concepts that are completely different but mostly about WSGI vs RPC.
> - The functionality of the init_host() hook and periodic tasks are
> available to both WSGI and RPC servers.
> - The Service class doesn't know anything about WSGI vs RPC servers,
> all that knowledge is moved into the Server base classes.
> - init_host() is renamed to init(), since the "host" bit is fairly
> - All green threads are spawned from the service's thread group.
>But, actually, I'm now starting to struggle with justifying the
>Server/Service split ... why do we need both?
Well I think the manager class is there because you don't *need* to
inherit from anything, just implement init() and if you want PeriodicTasks
then you inherit from PeriodicTasks. So it simplifies plugins I suppose.
But I get your point, if the above is not important then we could just
have launchers and services. Perhaps I can do this in common and nova can then
do the whole Manager-plugin thing.
More information about the OpenStack-dev