openstack team mailing list archive

[Alex Glikson <GLIKSON@xxxxxxxxxx>]

Can you elaborate what is the purpose of this database?
If we compare it to KVM support, the 'primary' location of VMs' metadata 
is in libvirt internal store (outside of Nova), and then it is cached in 
Nova DB, for Nova purposes.
A similar approach might make for bare-metal machines too -- keep 
'primary' metadata store outside of Nova, and a cache in Nova DB.

Regards,
Alex




From:   David Kang <dkang@xxxxxxx>
To:     OpenStack Development Mailing List 
<openstack-dev@xxxxxxxxxxxxxxxxxxx>, "openstack@xxxxxxxxxxxxxxxxxxx 
(openstack@xxxxxxxxxxxxxxxxxxx)" <openstack@xxxxxxxxxxxxxxxxxxx>, 
Date:   15/08/2012 06:32 PM
Subject:        [Openstack] Discussion about where to put database for 
bare-metal provisioning (review 10726)
Sent by:        openstack-bounces+glikson=il.ibm.com@xxxxxxxxxxxxxxxxxxx





 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


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp