Open Stack

On Aug 15, 2012, at 10:09 AM, David Kang <dkang at isi.edu> wrote:

> 
> Currently, a single bare-metal DB is shared my many bare-metal nova-compute.
> It is OK for us to make it not shared.
> Data-wise, it doesn't need to be shared among many nova-computes.
> One good thing about having one shared DB is its convenience of backing up and
> implementing fault-tolerance.
> But, we are OK to make it not shared.


I think the code should not depend on making it shared. That means switching the scheduler to get information via rpc. By default each node could just write to a local sqlite database. It could even create a db automatically if the db doesn't exist.

However, It seems ok to me to leave the current database structure so that the database could be shared amongst multiple computes if a deployer wanted to deploy it that way for backup reasons (they could change the config for sql connection). I would strive to keep the data minimal and separate. Allowing bare metal node a to change data for bare metal node b opens up security risks.

Longer Term Ideas: In order to alleviate the problem of management via bm_node_create/bm_node_destroy, you might consider storing the data needed in HostAggregate metadata. That way you could create and destroy using the api instead of running a command on the host. If the host aggregate metadata is not complete enough, another option would be an api extension that could rpc directly to the bare_metal_nodes, or perhaps we could look at adding the necessary information into the nova db somewhere.

Vish