Open Stack

This is good to hear, I've started on a bit of this as it's pretty
important to Bluehost's openstack installations. I'd love to
contribute back and not be running over each other on this. Are there
related bugs or subtasks that I could get assigned?

-Mike Wilson

On Tue, Oct 23, 2012 at 9: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