Open Stack

On 07/16/2012 05:22 PM, Eric Windisch wrote:
> 
> 
> 
> On Monday, July 16, 2012 at 16:59 PM, Sean Dague wrote:
> 
>> Is there any update on work towards the no-db-compute blueprint? Even if 
>> there isn't work done on it yet, has there been thinking on basic 
>> strategy to get there?
>>
>> I'd really like to see this one land for folsom, so would be happy to 
>> apply some effort here.
>>
> 
> 
> I believe drafter Russell Bryant has made some progress on this, but I'll wait for his response.

Unfortunately, I haven't really started on this until this week, but now
I'm planning to try to knock it out as quickly as I can.

There are a number of pieces of this.  The one that I'm working on this
week is sending full instance objects in the compute rpc api.
Currently, most methods take an instance UUID.  I will be changing it to
expect a dict with all of the instance data, instead.  This means the
nova-compute service doesn't have to pull this data out of the db on the
compute nodes.

The other piece related to instance objects is being able to update them
in the database.  I'll comment on that a bit more below.

A useful way to help would be to help take inventory of other database
access that we need to address.  Dealing with the instance objects in
the compute rpc api is going to take a good amount of work, so I haven't
looked much further yet.  I'm sure there are other angles someone else
could go after.

> I've personally introduced a related patch, which is still in (perpetual) draft status as a PoC, to access the database over RPC. This would remove the direct access from compute nodes to the database, although they could still write to the database.  If we can complete the trusted-rpc-messaging blueprint, this could become a secure solution. I don't expect that trusted messaging + granular access control will arrive any sooner than Grizzly, however. With luck, it might appear as a patch for Folsom. Needless to say, that might not be the fastest path to a no-db-compute feature, but it would be a "free" consequence of changes we're making to otherwise secure the system.
> 
> I'll happily provide access to the draft patch for those in Gerrit, to those that are interested.

Have you done anything on this since the initial draft you posted?  My
major design concerns with this are:

1) How do you ensure that this new db service isn't a bottleneck?

2) If the answer to #1 is to allow running more than a single instance
of it, how do you ensure database updates are done in order?

-- 
Russell Bryant