openstack team mailing list archive

[Michael J Fork <mjfork@xxxxxxxxxx>]

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

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

Does this solution seem workable? Anything I missed?

Michael

-------------------------------------------------
Michael Fork
Cloud Architect, Emerging Solutions
IBM Systems & Technology Group

David Kang <dkang@xxxxxxx> wrote on 08/15/2012 11:28:34 AM:

> From: David Kang <dkang@xxxxxxx>
> To: OpenStack Development Mailing List <openstack-
> dev@xxxxxxxxxxxxxxxxxxx>, "openstack@xxxxxxxxxxxxxxxxxxx
> (openstack@xxxxxxxxxxxxxxxxxxx)" <openstack@xxxxxxxxxxxxxxxxxxx>,
> Cc: mkkang@xxxxxxx, Ken Ash <50barca@xxxxxxxxx>, VTJ NOTSU Arata
> <notsu@xxxxxxxxxxxxxx>
> Date: 08/15/2012 02:08 PM
> Subject: [openstack-dev] Discussion about where to put database for
> bare-metal provisioning (review 10726)
>
>
>
>  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
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@xxxxxxxxxxxxxxxxxxx
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>