Open Stack

 The bare-metal database includes five tables:

1. bm_nodes   // This is similar to compute_node table
2. bm_deployments   // The status of deployment of bare-metal nodes
3. bm_pxe_ips   // PXE information for bare-metal nodes
4. bm_interfaces   // network information of bare-metal nodes
5. migrate_version  // for database migration

 The information of bare-metal nodes and their status 
are sent to the scheduler as an "aggregate capability set" of the bare-metal machines.
Our current approach is to have a new BaremetalHostManager (nova/nova/scheduler/baremetal_host_manager.py)
that caches the information.
BaremetalHostManager gets the information by accessing bare-metal db directly for now. (Proposed patch 4)
It works only when there is one shared bare-metal db exists.
But, it looks like that non-shared bare-metal db is preferred.
We will change BaremetalHostManager to use RPC (instead of db access) to access those information from multiple bare-metal nova-compute nodes. 

 Thanks,
 David




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

----- Original Message -----
> 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 at isi.edu>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>, "openstack at lists.launchpad.net
> (openstack at lists.launchpad.net)" <openstack at 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.com at 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 at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp