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