Open Stack

Other ideas that I have been shooting around.

http://wiki.openstack.org/RepairingOwnership + http://wiki.openstack.org/SchedulingSplitout

I am hoping to give it a go and see what happens.
Just hoping to avoid to much complexity which seems to kill new code initially (large changes bad…).

From: Joe Gordon <jogo at cloudscaling.com<mailto:jogo at cloudscaling.com>>
Reply-To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Monday, November 12, 2012 3:17 PM
To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [Nova] no-db-compute, a new service



On Fri, Nov 9, 2012 at 10:04 AM, Russell Bryant <rbryant at redhat.com<mailto:rbryant at redhat.com>> wrote:
Greetings,

Dan Smith and I are getting pretty close to finishing the first stage of
no-db-compute work for Grizzly.  Specifically, that means these two things:

1) Sending more data from the nova-api service to avoid db reads in
nova-compute.

2) Pulling db access out of nova virt drivers and having the only code
in nova-compute that touches the db in nova/compute/manager.py.

Removing the remaining db access is going to take some more drastic
changes.  This is what the majority of our discussion at the design
summit was about.  The idea of a db writer service (nova-sink) was
discussed, but the majority opinion seemed to be that if we're going to
make a big change to how nova-compute service, the "nova-sink" idea was
not enough.  I'd like to kick that discussion off again so that we can
settle on a specific direction forward.


Here's a proposal based on the suggestions from the design summit
session.  The intent is to generate some discussion around this so that
we can keep writing code knowing that we're generally headed in a
direction that others are happy with.

How about we create a new service called "nova-compute-proxy".  In
short, I would envision it looking very much like "nova-sink" in the
short term, but evolving into much more over time as we carefully rework
how some operations are handled.

This service would act as a proxy for nova-compute in a couple of ways.

1) The nova-compute service would use it as a proxy to accomplish
certain tasks, such as targeted operations that need database access.

2) Over time, it would be used as a proxy for other services that wish
to execute some sort of compute action.  For example, instead of
directly asking nova-compute to complete a long running operation, the
nova-compute-proxy would take this operation and monitor its progress.


Architecture notes:

The nova-compute-proxy service must be horizontally scalable.  You can
run as many of them as needed to scale out.  There is not a 1 to 1
relationship with nova-compute services.  While nova-compute services
have ownership of specific instances, this is not true of
nova-compute-proxy.


Evolution:

The most immediate short term goal is to remove database accesses from
the nova-compute service.  Certain database accesses will just be pushed
into nova-compute-proxy and exposed as methods that can be executed
using rpc.call().  One such example will be instance_update() since that
is used in many places in nova-compute.  I expect a lot of this to be
done in the near term.

Operations that are top candidates for being orchestrated by
nova-compute-proxy are operations that cross multiple compute nodes,
such as migrations and resizes.  However, there may be benefit in doing
this for other long running operations, such as starting an instance.
We should look into doing as much of this as is practical in this
development cycle, but I suspect much of this would carry over into H
development.


Some questions, complications, vagueness:

a) There is still a bit of hand waving around the more significant
functionality will work in nova-compute-proxy (something like resizes).
 It seems to make sense from a high level, but I haven't tried mapping
out exact order of operations or anything.  Does it seem to make sense,
or do we need to dive deeper?

b) How about periodic tasks?  Right now nova-compute does a number of
periodic tasks, mostly associated with cleanup for the local instances.
 If long term we want to simplify nova-compute, where do these go?
Short term, for no-db-compute, we can leave them where they are and just
use nova-compute-proxy for db access as needed.  It feels like we need a
good long term vision here though, and I'm not sure what it is.

If nova-compute-proxy was directly tied to N instances of nova-compute,
nova-compute-proxy could just do the periodic tasks.  I was hoping we
could not have to tie instances of the two services together because it
seems to leave the architecture more flexible and less complicated.

This sounds a lot like what nova baremetal is doing, where one service is managing many 'virt' machines.


Is the short-term approach for periodic tasks acceptable for now?

What should the long term plan be?  And does that have an impact on what
we do right now?


Thoughts?

--
Russell Bryant

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121112/8a4b147c/attachment.html>