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 <dk...@isi.edu> To: OpenStack Development Mailing List <openstack-...@lists.openstack.org>, "openstack@lists.launchpad.net (openstack@lists.launchpad.net)" <openstack@lists.launchpad.net>, 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....@lists.launchpad.net 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
