Open Stack

 Hi Mark,

 One of our co-developers Arata raised the following issues of having per nova-compute db.

* A different approach is needed to register/unregister nodes.
        When I register many new nodes have different corresponging hosts, I have to exec bm_node_create/destory on host by host in current approach.
* Because DB is distributed, full-backup may become difficult a little.

 His points are sound and reasonable.
When we have tens of bare-metal nova-compute, the issue becomes more serious.
How about having a shared db on a node (that can be one of bare-metal nova-computes or 
a node dedicated for this)
and let the bare-metal compute nodes share db through the node?

 Thanks,
 David


----------------------
Dr. Dong-In "David" Kang
Computer Scientist
USC/ISI

----- 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.