← Back to team overview

openstack team mailing list archive

Discussion about where to put database for bare-metal provisioning (review 10726)

 


 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.

 Thanks,
 David, Mikyung @ USC/ISI

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



Follow ups