Open Stack

----- Original Message -----
> Hi David,
> 
> On Wed, 2012-08-15 at 08:28 -0700, David Kang wrote:
> >
> >  Hi,
> >
> >  This is call for discussion about the code review 10726.
> > https://review.openstack.org/#/c/10726/
> > Mark asked why we implemented a separata database for bare-metal
> > provisioning.
> > Here we describe our thought.
> > We are open to discussion and to the changes that the community
> > recommends.
> > Please give us your thoughts.
> >
> >  NTT Docomo and USC/ISI have developed bare-metal provisioning.
> > We created separate database to describe bare-metal nodes, which
> > consists of 5 tables now.
> > Our initial implementation assumes the database is not a part of
> > nova database.
> > In addition to the reasons described in the comments of the code
> > review,
> > here is another reason we decided a separate database for baremetal
> > provisioning.
> >
> > Bare-metal database is mainly used by bare-metal nova-compute.
> > Since bare-metal nova-compute manages multiple bare-metal machines,
> > it needs to keep/update the information of bare-metal machines.
> > If the bare-metal database is in the main nova db, accessing nova db
> > remotely by
> > bare-metal nova-compute is inevitable.
> > Once Vish told us that shared db access from nova-compute is not
> > desirable.
> >
> > It is possible to make the scheduler do the job of bare-metal
> > nova-compute.
> > However, it would need a big changes in how the scheduler and a
> > nova-compute
> > communicates. For example, currently, the scheduler casts an
> > instance to a
> > nova-compute. But for bare-metal node, the scheduler should cast an
> > instance
> > to a bare-metal machine through bare-metal nova-compute.
> > Bare-metal nova-compute should boot the machine, transfer kernel,
> > fs, etc.
> > So, bare-metal nova-compute should know the id of bare-metal node
> > and other information
> > for booting (PXE ip address, ...) and more.
> > That information should be sent to bare-metal nova-compute by the
> > scheduler.
> >
> > If frequent access of bare-metal tables in nova db from bare-metal
> > nova-compute
> > is OK, we are OK to put the bare-metal tables into nova db.
> >
> >  Please let us know your opinions.
> 
> I just posted a comment in gerrit before seeing your mail.
> 
> The big question for me is whether the baremetal DB needs to be shared
> between compute nodes.
> 
> Right now, it looks like the DB is designed to be shared (e.g. the
> service_host column in the BareMetalNode) but could we re-work things
> so
> that it's not shared?
> 
> The big issue with a shared DB is the problems it causes for upgrades
> which we've been trying to fix with no-db-compute.
> 
> Cheers,
> Mark.

 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.

 Thanks,
 David