Open Stack

There are a number of advantages to breaking up nova-compute into hypervisor/non-hypervisor services:

1) Smaller code base on hypervisors (less resources required, less room for security issues)
2) Non-hypervisor code can have access to the DB
3) Some code from compute_api can move to the manager.  (Specific code I'm thinking of is the code handling 'delete' when there's no compute host or the compute host is determined to be down.)
4) Other code on the compute manager side that needs to consider _all_ instances can be better orchestrated.  For instance, I've noticed recently that there's some image cache code in the compute manager that requires knowledge of all instances.  All compute hosts are doing a lot of duplicate work.

etc.  I've also had this idea that it gets us closer to being able to remove AMQP access from the hypervisor service.  But I haven't fully thought it through, as it would somehow need to send messages back to the non-hypervisor daemon to update instance states. :)

The nova-sink idea makes a lot of sense.. but it feels like if we expand its role beyond the initial proposal, we can get a number of other wins as well.

- Chris


On Oct 23, 2012, at 8:27 AM, Russell Bryant <rbryant at redhat.com> wrote:

> Greetings,
> 
> The "no-db-compute" project is for removing direct database access from
> the nova-compute service.  The purpose of this message is to provide an
> update on the status of the effort.
> 
> You can find the blueprint here, but it doesn't contain details:
> 
>    https://blueprints.launchpad.net/nova/+spec/no-db-compute
> 
> There was a session on this topic at the Grizzly design summit.  You can
> find the notes from that session in this etherpad:
> 
>    https://etherpad.openstack.org/grizzly-nova-no-db-compute
> 
> A good amount of progress was made towards this goal in Folsom and we
> are intending to complete the project for Grizzly.  The work is
> primarily being done by myself and Dan Smith, but other contributions
> are certainly welcome.
> 
> This week we started doing an audit of the remaining database access
> that we need to address.  The notes are on the etherpad.  Our short term
> plan is to complete this audit and then continue to remove the database
> accesses that follow the pattern of all of the other "no-db-messaging"
> changes.  That means we can just send more data in the rpc message from
> the api service to avoid database reads in nova-compute.
> 
> Once we are down to the changes that require something more significant,
> which will primarily be writes to the database, we can discuss detailed
> proposals in the context of the specific operations.  We discussed two
> possible approaches in the summit session that both involve adding a new
> service.  One approach is a simple db writer service (nova-sink).  The
> other approach would be to start breaking up nova-compute into a
> nova-compute orchestration service that doesn't run on the hypervisor
> nodes and a more stripped down service that runs on the hypervisor
> nodes.  We can revisit the details once we have cut down the remaining
> problems to what must be solved by this new design.
> 
> Thanks,
> 
> -- 
> Russell Bryant
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev