<html><body>
<p><font size="2" face="sans-serif">I am interested in finding a solution that enables bare-metal and virtualized requests to be serviced through the same scheduler where the compute_nodes table has a full view of schedulable resources. This would seem to simplify the end-to-end flow while opening up some additional use cases (e.g. dynamic allocation of a node from bare-metal to hypervisor and back). </font><br>
<br>
<font size="2" face="sans-serif">One approach would be to have a proxy running a single nova-compute daemon fronting the bare-metal nodes . That nova-compute daemon would report up many HostState objects (1 per bare-metal node) to become entries in the compute_nodes table and accessible through the scheduler HostManager object. The HostState object would set cpu_info, vcpus, member_mb and local_gb values to be used for scheduling with the hypervisor_host field holding the bare-metal machine address (e.g. for IPMI based commands) and hypervisor_type = NONE. The bare-metal Flavors are created with an extra_spec of hypervisor_type= NONE and the corresponding compute_capabilities_filter would reduce the available hosts to those bare_metal nodes. The scheduler would need to understand that hypervisor_type = NONE means you need an exact fit (or best-fit) host vs weighting them (perhaps through the multi-scheduler). The scheduler would cast out the message to the <topic>.<service-hostname> (code today uses the HostState hostname), with the compute driver having to understand if it must be serviced elsewhere (but does not break any existing implementations since it is 1 to 1).</font><br>
<br>
<font size="2" face="sans-serif">Does this solution seem workable? Anything I missed?</font><br>
<font size="2" face="sans-serif"><br>
Michael<br>
<br>
-------------------------------------------------<br>
Michael Fork<br>
Cloud Architect, Emerging Solutions<br>
IBM Systems & Technology Group</font><br>
<br>
<tt><font size="2">David Kang <dkang@isi.edu> wrote on 08/15/2012 11:28:34 AM:<br>
<br>
> From: David Kang <dkang@isi.edu></font></tt><br>
<tt><font size="2">> To: OpenStack Development Mailing List <openstack-<br>
> dev@lists.openstack.org>, "openstack@lists.launchpad.net <br>
> (openstack@lists.launchpad.net)" <openstack@lists.launchpad.net>, </font></tt><br>
<tt><font size="2">> Cc: mkkang@isi.edu, Ken Ash <50barca@gmail.com>, VTJ NOTSU Arata <br>
> <notsu@virtualtech.jp></font></tt><br>
<tt><font size="2">> Date: 08/15/2012 02:08 PM</font></tt><br>
<tt><font size="2">> Subject: [openstack-dev] Discussion about where to put database for <br>
> bare-metal provisioning (review 10726)</font></tt><br>
<tt><font size="2">> <br>
> <br>
> <br>
> Hi,<br>
> <br>
> This is call for discussion about the code review 10726.<br>
> <a href="https://review.openstack.org/#/c/10726/">https://review.openstack.org/#/c/10726/</a><br>
> Mark asked why we implemented a separata database for bare-metal provisioning.<br>
> Here we describe our thought. <br>
> We are open to discussion and to the changes that the community recommends.<br>
> Please give us your thoughts.<br>
> <br>
> NTT Docomo and USC/ISI have developed bare-metal provisioning.<br>
> We created separate database to describe bare-metal nodes, which <br>
> consists of 5 tables now.<br>
> Our initial implementation assumes the database is not a part of <br>
> nova database.<br>
> In addition to the reasons described in the comments of the code review,<br>
> here is another reason we decided a separate database for baremetal <br>
> provisioning.<br>
> <br>
> Bare-metal database is mainly used by bare-metal nova-compute.<br>
> Since bare-metal nova-compute manages multiple bare-metal machines, <br>
> it needs to keep/update the information of bare-metal machines.<br>
> If the bare-metal database is in the main nova db, accessing nova db<br>
> remotely by<br>
> bare-metal nova-compute is inevitable.<br>
> Once Vish told us that shared db access from nova-compute is not desirable.<br>
> <br>
> It is possible to make the scheduler do the job of bare-metal nova-compute.<br>
> However, it would need a big changes in how the scheduler and a nova-compute<br>
> communicates. For example, currently, the scheduler casts an instance to a<br>
> nova-compute. But for bare-metal node, the scheduler should cast an instance <br>
> to a bare-metal machine through bare-metal nova-compute.<br>
> Bare-metal nova-compute should boot the machine, transfer kernel, fs, etc.<br>
> So, bare-metal nova-compute should know the id of bare-metal node <br>
> and other information <br>
> for booting (PXE ip address, ...) and more.<br>
> That information should be sent to bare-metal nova-compute by the scheduler.<br>
> <br>
> If frequent access of bare-metal tables in nova db from bare-metal <br>
> nova-compute<br>
> is OK, we are OK to put the bare-metal tables into nova db.<br>
> <br>
> Please let us know your opinions.<br>
> <br>
> Thanks,<br>
> David, Mikyung @ USC/ISI<br>
> <br>
> ----------------------<br>
> Dr. Dong-In "David" Kang<br>
> Computer Scientist<br>
> USC/ISI<br>
> <br>
> <br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.org<br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> <br>
</font></tt></body></html>